Recently, I’ve encountered several newcomers asking about the PLC scan cycle issues, it’s really frustrating! They keep making the same mistakes over and over again. After working in this field for over ten years, I’ve seen too many program crashes caused by a lack of understanding of the scan cycle principles. To put it bluntly, these recent graduates only learned theory in school and have no practical skills on-site.
The PLC scan cycle is actually not complicated, but many people just can’t grasp it. The old Siemens CPU scan process is divided into several steps: reading inputs, executing the program, diagnostics and communication, and updating outputs. The key point is that many people don’t realize these steps are separate! They think that changing a value will immediately reflect at the output… it’s laughable.
1
Common Pitfalls
I remember last summer, at a car parts factory in Suzhou, a new guy wrote a program to control the assembly line, and when it was run on-site, it blew up. The equipment refused to operate, and the production manager was as anxious as an ant on a hot pan. When I looked at the code, my first reaction was, “What the hell is this?”
The most common mistake is repeatedly reading and writing the same variable within a single scan cycle, thinking it will update immediately. For example:
// This code is nonsense
X := 10;
Y := X + 5;
X := X + Y; // At this point, X is still 10, not 15!
Z := X * 2; // So Z is 20, not 30
By the way, speaking of this, I remember a project at a power plant where the programmer insisted on completing all calculations and state transitions within one cycle, resulting in the program running away. These people write programs as if they are writing Java or C#, completely unaware of the PLC’s operating mechanism. PLC programming is different from regular programming languages; it does not execute sequentially!
Another major pitfall is those programs that frequently read analog values. I’ve seen people read a temperature sensor 50 times in each scan cycle and then wonder why the CPU load is so high… isn’t that infuriating? It’s like using a PLC as a server. I really want to delete all those messy tutorials.
2
Communication Issues
The communication part is the easiest to overlook in the scan cycle. Many beginners don’t know when communication is processed, thinking they can send or receive data at any time. I particularly dislike those who cram a bunch of Modbus read/write operations into the main program; this approach is a recipe for disaster!
Back in 2018, during a steel plant project with an old AB ControlLogix, the client insisted on handling all SCADA communication within the scan cycle. I told him it wouldn’t work, but he didn’t believe me, and as a result, the system failed during peak periods. Later, I had him move the communication tasks to a separate program block, and the problem was resolved.
By the way, different PLC brands handle communication differently. Siemens’ PROFINET is much stronger than AB’s Ethernet/IP in this regard, with better isolation between communication and program execution. However, I’ve seen many engineers who don’t even understand this basic difference and configure it blindly.
3
Simple Solutions
Actually, the solutions to these problems are not difficult; it’s about understanding how the PLC works. First, clarify how long your PLC scan cycle is! Upon reading this, some may ask, “How do I check that?”… just look at the manual, okay? The S7-1500 manual states it on page 143.
If you want to achieve continuous processing within the same cycle, you can use interrupt programs. I remember last year’s project at a pharmaceutical factory, where we used Siemens’ periodic interrupts to handle high-speed signals, which was many times faster than the main program OB1. However, be careful not to make the interrupt program too long, as it will affect the execution of the main program.
For those signals that need immediate response, don’t foolishly place them in the main scan cycle. Use event triggers or hardware interrupts; if you don’t understand this basic knowledge, what are you doing in automation?
As for communication issues, the simplest solution is to separate data exchange from logic processing. You can use a separate data block (for Siemens) or controller tags (for AB) specifically for storing communication data, and then use copies of this data in the program to avoid directly manipulating communication variables.
// Correct way
// In the communication block
CommDB.Temperature := HMI_Temperature;
// In the logic block
MyTemp := CommDB.Temperature; // Copy it before use
IF MyTemp > Setpoint THEN
Alarm := TRUE;
END_IF;
By the way, one more thing, never change inputs in the middle of a scan cycle! Some novices think they can modify the physical input values in the middle of the program, which is just ridiculous. Inputs are read once at the beginning of the cycle, and any changes made in between are useless; outputs are also updated once at the end of the cycle.
Today’s young people always look for shortcuts, thinking PLC programming is simple. As a result, when they get on-site, they can’t solve a bunch of problems and only know how to call for help. There are no shortcuts in this field; you have to practice more to master it. To be honest, just reading books won’t teach you these things; you have to experience system crashes and stay up all night debugging to truly understand the essence of PLC programming.
Lastly, let me reiterate, no matter which PLC you use, you must adapt to its operating mechanism, rather than expecting it to adapt to your programming habits. If you find these rules too troublesome, I suggest changing careers; don’t waste time in automation… factories are not a place for you to practice.
Before you leave, remember to click “Read”~