I really can’t stand those newcomers in the industry who ask the most ridiculous questions every day. Just yesterday, a guy came to me with a textbook asking why his ladder diagram program wasn’t working. When I opened it, it was a mess of logical relationships, and he couldn’t even distinguish between normally open and normally closed contacts. I’ve been using the old Siemens ladder diagrams for 15 years; it’s just the same few elements, how can you not understand it?
To be honest, PLC ladder diagram programming is not some advanced technology, but some people can complicate simple things. In 2019, at a paper mill in Suzhou, I met a young engineer who claimed to be an “automation expert”. He wrote a bunch of flashy programs, and as a result, the equipment just wouldn’t work. When I looked at his code, it was full of unnecessary nested branches and timers, making things unnecessarily complicated.
Seeing that confused look on the young man’s face, I didn’t even want to say anything.
The most basic elements of a ladder diagram are just these few:
| | | |
|-----| --|/|---------|/|------|/|---------|-----|
| | NC1 NC2 NC3 | |
| | | |
|-----| --|/|---------|/|--------------------|-----|
| | NC4 NC5 | |
| | | |
|-----| --|/|----------| |-------------------|-----|
| | NC6 NO1 | |
Such a simple thing, just draw it a few times and you’ll remember it quickly. Theory is useless; practical experience is the hard truth. I never look at those thick manuals; just looking at the table of contents is enough to find the functions I need. By the way, I’ve also used AB’s ControlLogix quite a bit, but compared to Siemens’ TIA Portal, it always feels a bit lacking… However, some people prefer AB, and that’s a matter of personal preference.
Speaking of debugging pitfalls, there are just too many. Last summer at a parts factory in Hebei, it was over 40 degrees Celsius on site, and an injection molding machine suddenly stopped, making the manager jump up and down. I went over to take a look, and it was all junk domestic PLCs; the communication module had failed. I restarted it several times according to the manual, but it was useless. The maintenance worker in the factory was sweating profusely, and when I asked him how he usually dealt with such problems, he said he just prayed the programming would work until it did… I was really speechless.
By the way, speaking of communication, I remember a control system from a few years ago that used the Profinet protocol, and as a result:
- Severe signal jitter
- Constant communication timeout alarms
- The entire system kept dropping
Where was the problem? The quality of the cables. You get what you pay for; that boss insisted on buying cheap network cables, and as a result, when electrical noise increased, communication was interrupted. I replaced it with genuine Siemens cables, and the problem was immediately solved. Some people only learn after suffering losses.
There are just too many modifications made on-site. I remember once when the equipment went online, we found that there weren’t enough I/O points. The customer was in a hurry to use the equipment, so we had no choice but to merge several less important signals into one input point and then use software to determine the state. This kind of lazy solution is definitely not a long-term plan, it hides safety risks, but at that time, we were really forced into a corner.
To be honest, ladder diagram programming is all about having a clear thought process. Those engineers who come straight out of university want to use structured programming right away, with a bunch of function blocks, but in reality, the simpler it is, the less likely it is to go wrong. Especially for fault diagnosis programs, I usually write it like this:
// Simple fault diagnosis example
M100.0 := I0.0 AND NOT I1.0; // Pressure switch fault
M100.1 := I2.0 AND T37; // Timeout fault
M100.7 := M100.0 OR M100.1; // Total fault flag
This code is clear at a glance, and maintenance personnel can see at a glance where the problem is. Unlike some people who write “advanced code” with layers of nesting, making it look like a maze, and when a problem arises, they can’t even find where it is.
Now I basically only use Siemens S7-1500 and 1200 series; their reliability is unquestionable. Those cheap PLCs that break down at the slightest provocation, I don’t even want to touch them. A few months ago, for a water plant project, the customer insisted on using a certain domestic PLC to save money, I told them it was unreliable, and as a result, the system malfunctioned three times in the first week; in the end, they had to obediently switch back to Siemens.
Also, the issue of performance bottlenecks is often overlooked by beginners regarding the impact of the PLC scan cycle. I’ve seen too many engineers stuff a bunch of complex calculations into the main scan loop and then wonder why the system is slow to respond. This kind of control delay is an old problem in industrial control systems; you either optimize the program or distribute the processing; there is no perfect solution.
In summary, ladder diagram programming is a skill that requires practice to master. Those who spend all day studying theory are often dumbfounded when faced with real problems. My more than ten years of experience boils down to: make more mistakes and summarize, so you can make fewer mistakes. Money isn’t earned for nothing, and skills don’t just fall from the sky. If you don’t understand something, ask, but before asking, try to do it yourself first; don’t just come to ask without doing anything… These electrical newbies are really…
Before you go, remember to click on “Looking”~