In PLC programming, everyone has their own approach. Even the same control logic will yield different results when written by different engineers. Even the same engineer may have different approaches at different times.
Therefore, when writing programs, two different programs can achieve the same function.
Since different programs can achieve the same function, then programs must vary in quality. How do we evaluate the quality of a program?
Here are some programming principles summarized by the editor:
1. Safety: PLC control inevitably involves some automatic operation. This part must be absolutely foolproof; it's better to omit it altogether than to leave the controlled object out of control. Manual operation should also include interlocking limit switches or time limits. Many mechanical devices have their own safety mechanisms; you should forget about that and ensure absolute safety for both personnel and machines through the programming.
2. Ensure complete functionality. While prioritizing safety, fulfill the customer's functional requirements to the greatest extent possible. This is where your professionalism shines; don't wait until equipment delivery to leave the sales staff unable to deliver. For any parts that cannot be implemented due to hardware or other reasons, communicate with the customer as early as possible.
3. Logically sound: Our program not only needs to complete each action smoothly when all parts are functioning normally, but it must also remain in the installation state and provide safety prompts even when certain signals are lost.
My experience over the years has shown that implementing functionality is easy, but handling exceptions is very difficult.
Human thinking is prone to flaws, especially when you're racking your brains to implement certain functions. Being meticulous and having flawless thought processes is indeed difficult. When programming, it's best to break down functions and have different engineers collaborate on them. This is also necessary when there's a shortage of personnel; find a colleague familiar with the process and have them responsible for verifying the program. Experiment repeatedly, modifying it step by step, until it can handle various operating conditions.
4. Simplify the program. While ensuring logical consistency and flawless design, the programming should utilize the simplest possible statements to accomplish as much functionality as possible. The program should be easy to modify, debug, and upgrade.
The general workflow of a program is as follows: clarify the process requirements, program design, debug, find problems, add (modify) functions, continue programming, debug again, and continue a new round of modifications, and so on. Therefore, your program should be easy to modify from the beginning of its design, and you should not make it so that "changing one thing affects the whole system", which will increase the difficulty for yourself.
5. Easy to read: Besides fulfilling the specified functions, our programs should also be easy to understand and use. Many projects cannot be completed by one person alone. If your program is easy to understand, team members can collaborate more effectively. In a harsh on-site environment, would you still be in the mood to debug a piece of garbage code?
In addition, variable names and comments should be clearly identified in the program and correspond to the drawings. This ensures that information within the program is easy to retrieve and find.
The scientific programming steps are actually quite simple, but most engineers often overlook many details because they think it's simple. Ignoring details will inevitably lead to problems later. To avoid future problems, you must strictly follow the rules. Without rules, there can be no order; PLC programming also has its own set of rules.
Step 1: Read the product instruction manual
The first step seems incredibly simple, but many engineers fail to do it. They consider it a waste of time, or even rely solely on supplier training to learn about the equipment.
Carefully reading the instruction manual is the first step in programming. First, you must read the safety guidelines to understand which actuators might cause personal injury, which mechanisms are most prone to collision, and how to handle dangerous situations. These most critical questions are all addressed in the safety guidelines, so why not read them?
Furthermore, the characteristics, usage methods, and debugging methods for each component of the equipment are also in the instruction manual. Without reading it, even if the program is correct, the equipment will still not work if the components are not properly debugged. Moreover, all the circuit diagrams, pneumatic and hydraulic circuit diagrams, and assembly drawings are also in the instruction manual. Without reading them, how can one know what modifications can be made to each component?
Step 2: Check the I/O according to the instruction manual.
The second step is to check the I/O, commonly known as "marking".
There are many ways to check I/O, but you must check them one by one according to the addresses provided in the manual, and only do so under absolutely safe conditions.
When inspecting input points, the input signals are generally nothing more than various sensors, such as capacitive, inductive, photoelectric, piezoresistive, ultrasonic, magnetic, and limit switch sensors. Inspecting these components is relatively simple; just place the workpiece on the workstation according to the component's specifications, or move the actuator to check if the sensor has a signal. Of course, different equipment may use different testing methods, depending on the specific circumstances.
However, extra caution is required when checking output signals. For electrically driven products, the actuator's drive must be energized under safe conditions, especially ensuring the equipment will not be impacted, to check if the actuator can move. For hydraulic or pneumatic actuators, similarly, manually energize the directional valve under safe conditions to control the actuator. When checking output signals, regardless of the actuator's drive method, always refer to the component's instruction manual. Prioritize equipment and personnel safety. Note that not all actuators can be tested by energizing them; therefore, sometimes individual output signals may not be able to be tested manually.
Whether it's an input or output device, when the sensor receives a signal or the actuator's drive is powered on, it's essential to simultaneously check if the I/O module indicator lights on the PLC are also illuminated. In many devices, input and output signals are connected to the PLC via terminal blocks. Sometimes, the terminal block indicator lights may show a signal, but this doesn't guarantee that the corresponding address on the PLC won't be connected due to an internal break in the connecting wire. This point requires special attention.
After measuring the input and output signals, record the measured addresses to ensure they match those in the instruction manual. If discrepancies exist, measure the device address again. If multiple measurements still yield inconsistencies, contact the device manufacturer first, as the manufacturer's address cannot be guaranteed to be correct at this point.
Step 3: Open the programming software, configure the hardware, and write the I/O addresses into the symbol table.
Different PLCs use different programming software. However, for any software, the first step before programming is hardware configuration, which involves establishing the hardware configuration and corresponding communication configuration based on the actual PLC type. After hardware configuration is complete, the I/O addresses previously recorded on paper are written into the software's symbol table. The definition of the symbol table may differ between software programs, but most software has this function, and this step is crucial. When writing the symbol table, not only should the absolute addresses of the device's inputs and outputs be written correctly, but it's also best to name each address and add comments. This will greatly facilitate subsequent programming. It eliminates the need to look up the absolute address every time during programming; simply enter the named address. Of course, this also depends on whether the software has this functionality.
Step 4: Write the program flowchart
Before programming, always write out the program flowchart on a draft. A complete program should include a main program, a stop program, an emergency stop program, a reset program, etc. If the software allows, each program should be written in a "block" format, that is, one program is one block, and each block can be called as needed.
PLCs excel at handling sequential control, where the main flow is crucial. It's essential to ensure the established flow is correct and to carefully check it on the draft. If the main flow has problems, when the PLC executes the program, collisions may occur, damaging equipment or posing a danger to personnel.
Step 5: Write the program in the software.
Once the main process is confirmed to be working correctly, you can begin writing the program in the software. Furthermore, pay close attention to the correctness of the stop, emergency stop, and reset procedures, especially the stop and emergency stop procedures. These are the most critical procedures related to personal and equipment safety and should never be underestimated. It is imperative to ensure that under any circumstances, executing the stop or emergency stop procedure will absolutely not cause any harm to personnel.
Step 6: Debug the program
The debugging process can be divided into two aspects.
1. If conditions permit, or if you have exceptional logical abilities, you can first use the software's simulation function to test, but many complex programs are difficult to verify through software simulation to determine if they are correct.
2. Download the program to the PLC for online debugging. If the equipment does not move or malfunctions during operation, do not modify the program immediately. It is likely that the sensors are not properly calibrated. Only modify the program after confirming that the sensors are working correctly.
Step 7: After debugging, edit the program again.
In the previous debugging step, since the program was modified, it is necessary to check or edit the program again before downloading the final program to the PLC.
Step 8: Save the program
In this step, it's crucial to consider where to save the program. PC hard drive? Flash memory? External hard drive? None of these are suitable, as all such storage devices are susceptible to virus infection. Therefore, the program must be burned onto a CD. Another question arises: which program should be burned? We have already downloaded the final, debugged, and modified program to the PLC. If the PLC executes the program flawlessly, we upload that program to the PC and burn it onto a CD.
Everything above is for safety.
Step 9: Complete the report
After completing the programming, you should fill out a final debugging report, recording all the problems encountered and any difficulties the program faced. This is because you may forget some of the programming techniques over time, and it also helps other colleagues understand the program you wrote.
