Hello everyone, I am Fan Hua. Today, let’s talk about the common mistakes in PLC programming that often trouble beginners. Whether you are a newbie just starting out, or an experienced practitioner, this article will surely provide you with some insights. After all, on the road of automation, who hasn’t stepped into a few pitfalls?

1. Confusing Normally Open and Normally Closed Contacts

Many beginners often struggle to distinguish between Normally Open (NO) and Normally Closed (NC) contacts when using relays or buttons. It’s like the light switch at home, which is usually “off” (i.e., in the open state), and only turns “on” (i.e., closed) when pressed. In PLC:

• • Normally Open (NO): Normally open, closes when activated
• • Normally Closed (NC): Normally closed, opens when activated

Practical Applications:

• • Use Normally Open contacts to control the start button
• • Use Normally Closed contacts for emergency stop protection

Note: When designing safety circuits, prioritize using Normally Closed contacts. This way, even if the circuit is disconnected, problems can be detected in a timely manner.

2. Ignoring Scan Cycles Leading to Program Errors

PLCs scan programs at fixed intervals, usually ranging from a few milliseconds to several tens of milliseconds. If your program logic does not take this into account, unexpected results may occur.

To detect a rapidly changing signal:

|   X0   |   Y0   |
|---| ---|---( )--|

This simple program seems fine, but if the X0 signal changes faster than the PLC scan cycle, Y0 may not respond correctly.

Solutions:

1. 1. Use high-speed counters or interrupt functions
2. 2. Increase input filtering time
3. 3. Include a latching circuit in the program

|   X0   |   M0   |   Y0   |
|---| ---|---( )--|---( )--|
|   M0   |
|---| ---|

3. Misusing SET/RST Instructions

SET (set) and RST (reset) instructions are powerful, but misusing them can be a ticking time bomb. I have seen people write the following:

|   X0   |
|---| ---|---(SET Y0)---|

|   X1   |
|---| ---|---(RST Y0)---|

At first glance, there seems to be no problem, but if both X0 and X1 are ON at the same time, the state of Y0 becomes uncertain.

Best Practices:

1. 1. Avoid using SET/RST to control the same output in multiple networks
2. 2. Use interlocking logic to ensure SET and RST do not execute simultaneously
3. 3. Consider using latching circuits instead of SET/RST

|   X0   |   Y0   |
|---| ---|---( )--|
|   Y0   |
|---| ---|
|   X1   |
|---|/|---|

4. Tragedy Caused by Mixing Data Types

PLCs have different data types, such as BIT, WORD, DWORD, etc. Beginners often accidentally mix them, resulting in inexplicable program errors.

For example: directly assigning the value of a 16-bit counter to a 32-bit data register.

MOV C0 D0  // This may cause data loss or errors

Correct Approach:

MOV C0 D0
MOV K0 D1  // Ensure the high 16 bits are 0

Reminder: When performing data conversions, always pay attention to data type matching and perform explicit conversions if necessary.

5. Neglecting Initial Power-Up States

Many beginners only consider the state during program execution, ignoring the initial state of the PLC when powered on. This may lead to unexpected actions when the equipment starts.

Solutions:

1. 1. Use the first scan flag (such as Mitsubishi PLC’s SM400) to initialize key variables
2. 2. Add an initialization segment at the beginning of the main program
3. 3. Utilize the PLC’s power-off retention feature to ensure critical data is not lost

|  SM400  |
|---| ---|---(RST M0)---|
         |---(RST M1)---|
         |---(MOV K0 D0)---|

6. Communication Protocol Mismatches

When communicating with other devices, beginners often overlook the consistency of communication parameters. For example, if the PLC uses Modbus RTU but sets the baud rate to 9600 while the slave is set to 19200, communication will fail, resulting in both sides staring at each other.

Practical Tips:

1. 1. Use an oscilloscope to observe RS485 signals and confirm communication status
2. 2. Write communication parameters in a prominent location, preferably in a unified configuration file
3. 3. Learn to use communication diagnostic tools, such as Modbus Poll

Practical Recommendations

1. 1. Set up a small PLC test bench with several switches, indicator lights, and a simple actuator (like a motor)
2. 2. Try writing a simple sequential control program, such as simulating a traffic light
3. 3. Deliberately create some errors mentioned in this article, observe the system’s response, and then correct them
4. 4. Develop good commenting habits in your programs to leave clear explanations for yourself or others in the future
5. 5. Regularly back up your programs and label version information
6. 6. Read the device manuals often, as they contain many hidden features waiting for you to discover

Remember, PLC programming is a practical art. Just watching is not enough; you need to practice, think, and even make mistakes. Every mistake is a step towards progress, and the more pitfalls you encounter, the better PLC programmer you can become.

Alright, that’s all for today’s content. I hope these experiences can help you avoid some detours. If you have any unique experiences to share, feel free to comment below. See you next time!