Today, I'm sharing a practical article to help you understand what a perfect PLC program looks like, and provides PLC programming standards and suggestions for practical work.
Design Requirements for a Perfect PLC Program:
A complete PLC program is not simply about making the system run; it also requires complete comments, a well-structured architecture, good scalability, a comprehensive alarm and protection system, and a pre-run simulation system.
1. Simplicity
Make the PLC program as simple as possible. Simplicity means using a standardized program framework and simple instructions. Broadly speaking, this involves optimizing the program structure and simplifying the program with flow control instructions. More specifically, it means replacing single-function instructions with more powerful ones and paying attention to the order of instructions.
2. Readability
The designed program should be highly readable. This not only helps the programmer better understand the program and facilitates debugging, but also makes it easy for others to understand and for users to maintain. It should also facilitate program dissemination when necessary.
To ensure good readability, the program design should be as clear as possible. Pay attention to hierarchy and modularity, even employing object-oriented design methods. Use standard design practices as much as possible.
If programming languages are used in special cases, ladder diagrams should be used in most cases for easier readability. I/O allocation should be systematic for easier memorization and understanding. Add comments when necessary. The use of internal components should also be systematic; avoid using them haphazardly.
Readability should be considered from the beginning of program design. This is not easy to achieve completely, because during program debugging, the addition or removal of instructions and changes in the use of internal components can make an originally clear program somewhat messy. Therefore, allow for adjustments during debugging in the design phase, and then tidy up after debugging. This will result in a higher quality program.
Program comments should at least include the following:
A. System comments: Copyright holder and purpose of the entire program; B. Block comments: Main purpose and author of the block; C. Segment comments: Purpose of the code segment; D. Variable comments: Importance self-evident, including I/O comments and intermediate variable comments. Regarding confidentiality considerations, these should be addressed through the encryption algorithm or block encryption of the program, rather than by reducing comments.
3. Correctness
The PLC program must be correct and verified through actual operation to prove its correct function. This is the most fundamental requirement for a PLC program; if this is not achieved, no matter how good the other aspects are, they are useless.
To ensure program correctness, instructions and internal devices must be used accurately. Accurate use of instructions is linked to accurate understanding of them; therefore, the meaning and usage conditions of instructions must be thoroughly understood. If necessary, small programs can be written to test some unclear instructions.
For the same instruction, due to differences in PLC manufacturing batches or series models, some instruction details may vary. The programming manual should be carefully consulted.
The correct use of internal devices is also important. For example, some PLCs have power-down protection, while others do not. It is essential to ensure that devices requiring power-down protection are used, and vice versa.
In short, the most fundamental requirement for PLC programs is to accurately use instructions and correctly utilize internal components to ensure the programmed program executes correctly.
For a simple example, Siemens PLCs require variables with storage functionality as intermediate variables for rising and falling edges, such as M-points or DB-points. Using FC's temp variable would cause problems.
4. Reliability
Programs must not only be correct but also reliable. Reliability reflects the stability of the PLC program, which is also a basic requirement.
Some PLC programs work correctly under normal operating conditions or during legal operations, but fail to function properly under abnormal operating conditions (such as a temporary power outage followed by rapid power restoration) or after illegal operations (such as pressing buttons out of sequence or pressing several buttons simultaneously). Such programs are unreliable, unstable, or poorly designed.
Good PLC programs can identify abnormal operating conditions and seamlessly integrate them with normal conditions, allowing the program to adapt to various situations. A good PLC program can reject illegal operations without leaving any "trace," accepting only legal operations.
Interlocking is a common method for rejecting illegal operations; relay circuits often use this method, and PLCs can also inherit this approach.
5. Ease of Modification
A program should be easy to modify. One of the characteristics of a PLC is its convenience and flexibility in adapting to various situations. This is achieved by modifying or redesigning the program.
Redesigning the program is used when the application requirements of the PLC's process need to be changed. Not only is the program rewritten, but I/O also needs to be reallocated. In most cases, rewriting the program is not necessary; minor modifications are sufficient. This requires the program to be easy to modify.
Ease of modification also means flexibility, requiring only minor changes to achieve the purpose of changing parameters or modifying actions.
6. Expandability
Many programs may be pre-programmed before deployment to the site, but additional programs may need to be added on-site. To avoid disrupting the overall system structure, sufficient space needs to be reserved in each functional area for backup hardware. The software should be designed with manual, automatic, and semi-automatic operation in mind, and space should be allocated accordingly.
7. Comprehensive Alarm System
PLC systems are often used in industrial environments, where every accident can cause losses, large or small. To ensure accident prevention or minimize losses during an accident, the PLC's alarm and protection functions must be emphasized. Therefore, this is highlighted as an important component of the system.
8. Program Simulation
To ensure on-site debugging progress or for customer demonstrations, a fully automatic simulation of the program is often required before deployment. This necessitates adding a simulation program section to the existing program, which is disconnected after normal on-site operation. To enable the program to perform simulation, the following steps are required:
(1) Convert the actual PLC I/O points into intermediate variables or data block variables;
(2) Write simulation programs for each piece of equipment according to process requirements.
A good PLC program can be considered one that meets the above requirements.
PLC Programming Specifications
1. Select the appropriate PLC model and I/O point count. Choose special function modules for specific functional requirements.
2. Be familiar with the selected PLC programming instructions and compilation software.
3. Plan the soft components, including internal relays, holding relays, data registers, timers, and counters.
4. Plan the program, generally following the sequence of fault extraction, fault handling, manual handling, automatic handling, and output handling. Larger projects or equipment should be divided into functional units, such as elevators, transfer devices, and lifting/rotating devices in an automated production line. These should be programmed in segments and blocks according to the above unit structure.
5. Add brief segment comments before each segmented or block-based program, explaining its function. If necessary, indicate the corresponding process flow. The order of segmented or block-based programs within the overall program should generally follow the process flow sequence for readability.
6. Before program design, the equipment should be abstracted. Common factors such as stop, emergency stop, overload, over-limit, timeout, safety light curtain, collision stop, and door switch should be extracted and placed in the start-up circuit or start-up main control and interlock circuit. This serves as the overarching premise of the entire program structure. Based on this, the program is then divided into two main functional areas: automatic and manual.
7. Common factors in the manual function area of the program structure, such as manual operation and factors endangering equipment and personal safety, should be extracted and placed in the manual main control and interlock circuit to protect, shield, and alarm for manual control.
8. Common factors in the automatic function area of the program structure, such as automatic operation, over-limit, and timeout factors, should be extracted and placed in the automatic main control and interlock circuit to protect, shield, and alarm for equipment under automatic control. A general principle is to strictly restrict equipment entry while loosely restricting equipment exit, ensuring safety.
9. A master reset function should be designed in the program to facilitate quick and easy restoration of normal equipment operation in case of malfunction. The master reset should fully consider the safety of equipment and personnel during the reset process.
10. When switching from automatic mode to manual mode, the program should clear the outputs and intermediate states from automatic mode. Especially when using the SET instruction in automatic mode, it must be cleared using the RESET instruction in manual mode.
11. Dual outputs are strictly prohibited in programming; that is, the same output statement or the same output coil appearing two or more times in the program. For the same output point under different mode conditions, use an intermediate relay for transfer, and finally combine them into a single output point.
12. When using a touchscreen, the control area and status area shared by the touchscreen and PLC must not be used for other functional programming.
13. Before using any special PLC module, check whether its control area and status area occupy working words. If so, do not program these working words for other purposes.
14. PLC inputs, outputs, intermediate relays, timers, counters, and data registers must be annotated with Chinese characters. Inputs and outputs must also include component names and tag numbers. The corresponding input points are generally defaulted to NO contacts connected to external switches. For inputs requiring NC contacts, this must be specified in the comments. All comments should be clear and unambiguous, avoiding misunderstandings, and minimizing the use of generic terms.
15. After project debugging is completed, the final software program must be retained. The saved file name should include the project number, author, date, and version number.
16. Regarding program encryption: The password for the encrypted program must be stored in a dedicated file, clearly indicating the username, password, and permissions. This file should be distributed to at least two people to learn the password and prevent the program from being inaccessible due to password loss.
Programming Suggestions
1. When a PLC and a host computer (or touchscreen) form a monitoring system, the screen often needs to display control modes such as "manual" and "automatic" (generally, multiple modes can only have one). The "MOV" instruction can be used in the program. For example, when "manual" is selected, the constant 1 is MOVed into register VB10; when "automatic" is selected, 2 is MOVed into the same register VB10. By checking the data in the register, the control mode of the system can be determined. The advantage of this approach is its ease of understanding and avoids the need for complex procedures like interlocking.
2. When the program involves analog signal control, if the read analog signal has virtually no error, time filtering can be used to delay the input. If the read data has a large error, other filtering methods are needed, such as averaging. Refer to relevant documentation for further information.
3. During program debugging, if a condition is met but the output coil is not activated, check if this section of your program is within such statements, such as `JUMP go to`. Another possibility is that after a program interruption, the condition is met but there is no output; this usually indicates that this section of the program is not being scanned.
4. In sequential control programs, i.e., when one action is completed and the next action is initiated, the +10+10 control mode is very convenient. The idea is as follows: A register is preset to 0 during initialization. After system startup, it is incremented by 10, bringing the register value to 10. With the register at 10, the first action can be performed. After the first action, the register is incremented by 10 again, bringing the register value to 20, allowing the second action to be performed. After the second action, it is incremented by 10 again, bringing the register value to 30. This way, by checking the value in the register, the desired action can be determined. When a jump action is needed, the increment can be changed from 10 to 20, 30, etc., depending on the specific requirements.
Why increment by 10 instead of 1? Because after incrementing by 10, if a segment needs to be inserted, it can be inserted into any of the 10 available slots.
5. When designing a program, if a process-related fault (not controlled by the control system) occurs, it is best to maintain the fault phenomenon and provide visual and audible alarms until the operator resets the system, so that they are aware of the fault. Otherwise, if the system stops, others may assume there is a problem with the program. These points should generally be considered when designing a new system.
6. Frequently called subroutines can be made into submodules for frequent calls.
7. Since each step in the work cycle of a production machine requires a certain amount of time to execute, and these times have certain limits, a timer can be started simultaneously with the start of the step to be monitored. The timer's time setting should be 20%–30% longer than the normal duration of the action. The timer's output signal can be used for alarms or automatic shutdown devices. When the time of a step exceeds the specified time, reaching the corresponding timer preset time, and before the next step begins, the timer issues a fault signal. This signal stops the normal working cycle and initiates the alarm or shutdown procedure; this is what we commonly call over-cycle protection.
8. Some safety detection switches (such as emergency stop buttons, safety light curtains, limit switches, etc.) should use normally closed (NC) inputs.
9. For safety and energy saving considerations, outputs should be designed to activate only when needed and stop once the action is completed, rather than being designed to output continuously until a stop is required.
10. The operating principle for actuators should be: better to remain still than to move erratically.
11. Single-unit equipment control: Each unit must have a manual/automatic switching function, and a start/stop function during manual operation. When switching from automatic to manual operation, the equipment must not stop; when switching from manual to automatic, the equipment's start/stop depends on the automatic program.
12. Each unit of equipment (pump, fan, and other large equipment) must be rotated after 24 hours of operation, and there must be a cumulative running time record, unless the start/stop sequence is set by the host computer; otherwise, the operator must set it manually.
