Click the blue text for more exciting information
I have been in the PLC industry for nearly 20 years, working on the front lines. To be honest, seeing those freshly graduated young people programming makes me laugh. They hold onto a pile of theories talking about control algorithms, yet they can’t even understand a simple ladder diagram. Today, I will discuss some aspects of PLC, especially the pitfalls of ladder diagrams and HMI interactions, hoping it will be useful for you electrical novices.
Let’s start with Siemens. I’ve been using the S7 series for over ten years, and it’s really good. A couple of years ago, at a paper mill in Suzhou, the client requested to use domestic PLCs, and I thought, here we go again. Sure enough, the instruction set of that piece of junk was completely different from Siemens, and the logic processing was a mess. Although domestic PLCs are cheap, they are far inferior in stability. That project almost got delayed due to communication timeout issues, and we had to switch back to the S7-1200 overnight to resolve it.
In fact, PLCs are all about understanding the scan cycle. Many beginners don’t get it and keep asking why the program doesn’t execute correctly or why data collection is lost. It’s all due to the scan cycle! Unlike microcontrollers, PLCs scan inputs, execute programs, and update outputs periodically, with cycles ranging from a few milliseconds to several tens of milliseconds. No matter how fancy your program is, if you don’t consider the scan cycle, it will eventually fail.
About Ladder Diagrams
I have always believed that ladder diagrams are the most intuitive PLC programming language. Don’t talk to me about ST or FBD, ladder diagrams will always be the first choice, especially for handling simple logic and relay control. However, ladder diagrams also have pitfalls, the biggest issue being the execution order. Last week, I visited a chemical plant and saw their ladder diagrams were simply terrible, with all sorts of cross-connection conditions, a complete mess.
Let’s look at an example:
|--[ ]--| |--[/]--|
| X1 | | M1 |
| |---(M1)-| |---(Y1)---
|--[ ]--|
| X2 |
Do you understand? This is the simplest self-locking circuit. If you can’t understand this, you shouldn’t be in the PLC industry. But the problem arises: where do you place the normally open contact M1? Should it be before or after X1? In parallel or in series? These are all important considerations. I remember in 2018, a hardware engineer wrote the self-locking circuit incorrectly, almost causing the injection molding machine to stop, and luckily I caught it early; otherwise, we would have lost hundreds of thousands in production value.
Speaking of this, I remember that AB’s PLC handles ladder diagram execution order more clearly than Siemens, especially the ControlLogix series, which scans from left to right and top to bottom, making it clear who updates first and who updates later. But AB’s prices are ridiculously high, often costing tens of thousands, which small projects simply can’t afford, unless it’s a foreign-funded enterprise willing to spend on such configurations. Domestic manufacturers shake their heads at the quotes and insist on using those unreliable cheap products.
HMI Interaction Pitfalls
Now that we’ve talked about PLCs, let’s discuss HMIs. The communication between HMIs and PLCs is the most prone to issues. Communication timeouts, data loss, and handshake failures can all drive you crazy. Let me tell you, there are a few points to pay attention to when working with HMIs:
Variable mapping must be done properly! Don’t just map directly to the DB block to save trouble, or one day when the DB block changes, the entire screen will be messed up. Let me tell you, last year at an auto parts factory in Wuhan, their engineers directly mapped over 100 variables one-to-one to the DB block, and when the PLC program was upgraded, the entire touchscreen was filled with question marks. They had to modify it on-site for two days to restore it.
Also, regarding communication protocols, Profinet is fast but has high cable requirements. In a complex factory environment with a lot of interference, it often results in disconnections. I personally prefer using Modbus/TCP, which is slower but more resistant to interference, cheap, and easy to use. The Japanese love to use CC-Link, which is incompatible with everything else, making integration a headache every time.
Programming Suggestions
Let me share some experiences I’ve summarized over the years. The programming mindset is very important, start with the overall structure before diving into details. I’ve seen too many people get caught up in writing complex functions right away, resulting in a chaotic overall architecture and difficulties in later expansion. First, clearly define the main functional blocks and allocate I/O, then gradually fill in the details.
For handling emergencies, safety comes first, everyone! No matter what the efficiency is, can you take responsibility if an accident occurs? All dangerous operations must have interlock protection, and don’t skimp on redundancy where it’s needed. I remember last year at a factory in Hebei, to save a few safety relays, the servo motor lost control and almost severed a worker’s hand, resulting in compensation of hundreds of thousands.
And comments! Can you write some comments while coding? Three years later, you won’t even understand your own code! Especially for some special algorithms and timing controls, clearly explain why you did it this way. I often take over other people’s messes, and when I open the program, I find thousands of lines of code without a single comment; it’s a disaster.
Finally, let’s talk about debugging. Don’t listen to those theorists babbling about simulation verification, this industry is all about practical operation, as the differences between virtual environments and real sites are huge. Noise interference, temperature changes, and power fluctuations are all issues. Debugging should be done step by step: first unit testing, then connections, and finally the system. Solve problems immediately as they arise, don’t leave them until the end.
Alright, I’ve said so much, hoping it will be useful for you newcomers. Don’t listen to those engineers who only know theory; when you get to the site, practical operation is the hard truth. If you have any questions, feel free to ask me; although I may have a bad temper, I can still solve problems.
Disagree with me? Just watch me!
