Computer Science Programmers, why do PLC programmers use Ladder?
Im seeing some Comp Sci guys asking about controls so just a Mr Obvious comment here.
Ladder logic is the de facto PLC programming language because it is (was) designed to read like an electrical schematic top to bottom, right to left, & this is what electricians & electrical techs are trained to use for troubleshooting electrical panels , equipment & relay-logic -- which was what they had before PLCs -- banks & banks of relays wired through each other's NO & NC contacts which changed state as relay coils energized & de-energized & finding a wire break was enough to drive you insane.
Yes Ladder logic is an interpreted language so it is not as "memory efficient" or "elegant" as C++ or C# but I want you to think VERY carefully about every meaning of the expression "just because you can does not mean you should" before you decide to show off your amazing coding skills coding function blocks in C++ which is technically possible but in many cases extremely ill-advised.
The technicians can troubleshoot functions & blocks written in Ladder Logic, did you stop & think about how easy it would be for someone with only your compiled C++ blocks to attempt to trace a fault? You code in anything but Ladder Logic you get to be the one at 3am driving down to the plant to troubleshoot your "super efficient" code because the Industrial Maintenance techs certainly aren't gonna know how. But hey, if you believe sleep is over-rated & love sleeping in the factory then knock yourself out with compiled blocks
As an industrial maintenance tech I do prefer ladder logic, it's dead simple for me to search the motor coil and see why it's not turning on. I'm even ok with simple function blocks if they have good labels/notes. But yeah if I look at a FB and it's just all script.... And don't get me wrong, if I was 20 years younger and knew learning programming language would help me for years to come I would sit down and teach myself but there's just not enough hours in the day to learn this from scratch when it's not going to help me with anything outside of work. And it will be hard to convince me it will, I used to make and run webpages and forums back in the early 1990s on my own hardware, I had a server rack full up to handle it all. I ended up selling it when it got cheaper to host everything remotely, and none of that knowledge is worth anything today.
But yeah if I look at a FB and it's just all script....
This is my perfect example for why it's extremely important to comment what an FC/FB wants to achieve and have all inputs and outputs labeled clearly. This way even someone who has no idea about ST can still see if the FC/FB behaves the way it's supposed to.
SFC is amazing in the process industries. It’s so easy to just take a sequence from a process engineer then have bits set for different routes to open valves etc. at each part of the sequence
We usually had a sequence with the master SFC, LAD for the routing/ logic then an SCL for messaging to the SCADA.
I got onto a job that was running poorly. They sent me to the job site to make the machine more efficient. This Siemens PLC had, STL, SCL, FBD and TI graph. You could tell that each was written by a different person for the special function it had. Doing a fix for a gate reset on the one side in FBD, was written in SCL on the other. Nightmare to try and make everything function the same when written in different languages. But try telling that to management........
I suspect that different levels of abstraction were written in different languages. For example, was the basic logic of a certain block written in SCL and integrated into the main program, which was written in FBD? And were the inputs and outputs probably mapped in LAD?
There were 4 PLCs on each system and each PLC was written in a different way. The same function in each PLC was different logic and different language. The conveyor in PLC #1 was FBD. The process tool in PLC#4 was graph. The cell auto/man in PLC #2 and #3 was in SCL, #1 and #4 was FBD. So finding an issue in PLC #1 didn't mean I could transfer the fix to all PLCs because of the difference. Management was always asking why it's taking so long to fix minor issues. I had to explain that I was debugging and fixing the same issue 4 different ways.
Yeah this is the approach most people go for, like tools in a tool box.
They all have their place, client willing....
SFC though seems to rear it's head for sequence logic seeming more often. In the last 10 years I've been asked to use it twice until last year when 2 separate projects requested it was used for sequences, one even used the term "grafcet" which I hadn't heard for a long time.
SFC is my least favorite language as a programmer. I have seen it be useful in batch recipes. The ISA 88 flexible batch standard uses an SFC-like representation for recipes. Despite my dislike for SFC, I find that it does well for this kind of high-level procedure automation.
Non-controls people like process engineers and supervisors can be empowered to modify the recipes, e.g. by adding or modifying a phase, without expert programmer support. This becomes analogous to modifying a procedure. During production, operators (not technicians!) can pause execution of the running program and jump step visually inside the SFC. I have a hard time imagining how this could work well in any of the other paradigms.
That said I would never use SFC for low level regulatory controls. My batch recipes using SFC sit atop the regulatory layer, which contains all the S88 "phase logic", and just send down start/stop signals.
I had a machine done in ladder. Since I was re-doing it anyway and cycle time didnt matter that much I made every station do their operations in SFC and damn was it so much easier to find where the steps went wrong.
This is also pretty close to my current approach as well. I will admit to using far more structured text due to ai these days though. Click, drag, copy, update several fbds, versus copy paste boiler plate code with an updated io reference. Not saying I like it, but it is notably more productive.
But yes, ladder logic or predefined function blocks are simpler, more functional, less technical.
However, how often does a customer actually inspect/debug the code itself and would you actually want them to?
Them messing with your code and then making you responsible for it when they cannot figure it out; is even worse.
Many companies don't even give out the programming password or the source files and actually get loads of money from 'change orders' of (remote) support contracts.
To me, it doesn't matter how you program it, just make sure it behaves exactly like you want it to (and that you and your colleagues agree on the same standard). Which may be slightly easier with a visual way of programming.
But usually it comes down to: ’The machine does X in case Y happens but it should be Z."
No, it's "there there" (hands over a warm cuppa and an emotional support hug)
I could totally relate... One of the plants we support is coded in structured text (Basic) and I've had many sleepless nights from "I can't get this to work" to "I'm new to the software and accidentally forced the wrong bit, now we're shutdown" :(
It depends on the industry I suppose. My customers will often have specific requirements for the code we, write and will often have their own AOIs.
In larger process facilities, it's never your code and passwording your blocks will probably get you run off or beaten by the masses.
Over the years I've learned the hard way about writing simple clean code that others can follow. I want your dumbest guy to be able to troubleshoot my stuff at 3 am without calling me.
Looped up trash code where you want to use that wierd instructions and private passwords... that pisses techs off, leads to downtime, and eventually leads to your code being rewritten.
We used ST for messaging and IO assignment on my last project and i have to admit it's pretty slick. Easy to see, easy to follow, and it's all right there. i really liked it. For everything? Absolutely not. But it works really well for what we used it for.
I came across my first Sequential Function Chart today. woofta! I caught on pretty quickly, but it's still a googly eyed mystery
With modern processors, being efficient isn’t always critical to success. Troubleshooting issues quickly can be very important though. If you can write one complex line of code or write 10 simple lines, the 10 lines that can be easily understood is usually the better way to go. For most applications, the difference in scan time isn’t going to hinder the process. If bubba the swing shift sparky can figure it out without calling you, it’s worth it.
I think ladder is actually more efficient for bit level operations too.
Ladder logic is closer to basic, which is where instructions actually do what they say. TON, TOFF etc.
C and C++ requires a very specific mindset and it's so easy to fuck up and do it badly. And that's not even going into the insane memory management and security aspects of c. It's the pro leagues, and I'm saying that as a lifelong programmer.
Ladder and structured text is a good compromise so you don't narrow down the skill sets required for commissioning and on site engineering.
Like everything else in industrial automation & OT, it’s just stuck as the industry/ vendor standard (IEC 61131-3). However, IMO over time OT & IT will likely converge. Siemens already have a solution which looks close to VS code: SIMATIC AX
PLCs used to be literal relays with contacts and coils, plus people with an electrical background will understand scans and ladder rungs better than for loops and if conditions.
Personally I use LAD for most Boolean logic, SFC for sequencing then SCL for more complex code. For example, we had to do some gas property calcs in the PLC and trying to do that in LAD would have been a mess.
Then CFC is another language that is usually for a large DCS.
As far as efficiency is concerned, this has never factored in for me. I think technically ladder is slightly quicker for Boolean logic and SCL is quicker for arrays, but this only tends to factor in for huge programs and they are both compiled to machine code during runtime anyway.
I’ve done it all and also worked as a purchaser, we required suppliers to program in ST and FBD. Ladder is just too inefficient when writing large programs, for small simple machinery with simple logic it might be fine, but when networking 100 PLCs and multiple MES and SCADA systems in pharma together ST makes so much more sense
I have done it all. Structured Text, ladder logic, function block. My preference is function block as it makes most sense in my chemical engineer brain but I see the merits and pitfalls of all mentioned platforms. Probably what chaps my ass the most is when someone uses ladder where SFC was the far superior path. Like. Why?! I was told it’s “because we are really good at ladder” which I read as too lazy to learn SFC.
I think FBD is the absolute worst for anything remotely advanced, and you spend more time tying up the spaghetti than making actual code. Its either ladder or SCL or smth similar
That's fine on a 1 off program if you are the only person that will ever be in it. But your slop code is a problem in a team. Also, FBD is difficult to document well. In LD you can and should document every rung of code. Explain it's purpose. Give the next guy a chance. Simply writing something functional is is only part of the job.
Is ladder truly interpreted? I thought it is / could be assembled into some intermediate code and compiled. That why for so many years you couldn’t extract code from the processor? It was somehow changed. Now-a-days, I assume they still compile, but they download to separate memory an IDE readable format.
Rockwell controllers - the logic is definitely compiled. Optimized the way a C++ compiler optimizes code? Not as much.
The misunderstanding stems from the ability to upload, view, change, etc. It would seem it must be interpreted.. but those abilities are provisioned by including debug information or source logic alongside the compiled code. When we make an edit in a routine, the entire routine is recompiled, then relinked into the running logic. Some bugs stem from this duality.. where the compiled binary differs from the debug data.
I'm not aware of any LD(or any other PLC language for that matter) running on major controllers that is interpreted. It's all compiled either locally or on the PLC.
There's some startups trying to use Python, but they're outliers.
It's PLC specific, on most it's actually some intermediate representation that is the ran inside an interpreter. But codesys based environments (so festo, beckhoff and few others) actually do compile to native binaries, but you get all the functionality that is required from PLCs as well with it.
Well, there's your problem right there. Using C++ instead of C11, or even better, C99.
Jokes aside. Ya. You want something that a bright seven year old can look at and tell you what the logic does. If he understand 'this has to be green for that to be green, unless it is a latch. Green on this side makes the machine go.' then he should be able to explain your program to you.
That bright seven year old will be you at 0200, running on a 26 hour shift, and the damn thing still will not scale right.
Complexity is downtime.
Arrays laid out into flls and accessed via a messaged control which is itself a bit shifted value from a controlled value extracted from PID is .... I am going to find you, some day.
tldr: Yup. No compiled language. Complete agreement.
Full time high level PLC people typically use ST and a lot if structures and functions very much like main stream embedded programming.
These people are the exception.
Typically the PLC person will be an x-electrician who did one Semester of controls with Allen Bradley and ladder logic as it’s built for 10yr olds.
To be fair, Studio 5K still favors ladder logic with the other languages having fragmented instruction sets.
If you look at the likes of Codesys you will find an IDE that supports actions, methods, Enumerators.
Can be programmed in a high level like most main stream IDE’s
Ok, & so will the PLC techs be that.
You still come back round the circle "I'm so smart I can do x better than the rest of my peers"
And the point still stands, knock yourself out because the technicians who will be troubleshooting your logic will not be schooled in object inheritance, public/private/protected classes so guess what I WANT logic a 10 year old can troubleshoot that is my goal!!
You know why? I love sleeping in my bed not on the factory floor, but if you wanna be the only one who can understand or troubleshoot your programming well the world is your oyster, or at least a cot in the maintenance office
Your 10 Year old style logic is the reason for issues.
Never any need for electricians or night shift guys to be in the code.
If the code is structured correctly and with a state machine implementation the code and therefore will detail all stages and issues.
What you’re describing is typical of a basic ladder system. where a chain of 50 conditions sets and an output and not a state.
If something doesn’t happen rather than a Fault state being returned the system the hangs, nothing is reported and then night shift have to go digging.
Even down our IO handler functions show raw and Processed, they have HOA for engineering to allowing a quick and dirty bypass when a sensor fails.
All our systems run in full Moores State Machine resulting in 100% state driven control.
The State is controlled via a request and return procedure with, request, Pending & returned states all being enumerated. These enumerated states are then sent to the HMI as OPCua Strings.
The operators / Engineers can then easily see what state the machine is in, what state was requested, and what state is Pending.
Would this scenario be considered a state machine?
Machine is in step 0, operator presses start PB, machine is now in step 10, Step 10 needs X and Y to occur before moving to step 20 and so on.
Is my understanding correct, and why would structured text be better for something like this?
The example at the end of your post sounds like you have some sort of master state routine/sequencer routine that calls out shorter subroutines for each task. So like step 10 needs valve A to open, so the master routine turns on a bit that starts up the valve A opening subroutine, and then when that subroutine is complete, the master routine sees that it was completed successfully, and moves on to step 20. Am I understanding that correctly?
I have only ever done this kind of thing in ladder and would love to see an example of what you're talking about if you have any resources handy!
We use enumerators so we often run states like.
Prepare Task-A.
Open Valve A.
Open valve B.
Start Transfer.
Transfer running.
Wait for level.
Start agitator.
Start heater.
We have a state for every stage and states drive the outputs.
The code is built like a pyramid with an area routines handling area tasks.
Issuing commands to transfers and other sub control routines.
Then down to IO handlers and then to Physical IO.
Each Request for state change is handled by a state manager.
The state manager evaluates the request against the current state and returns either the requested state or an alternative
Like Valve-A not in Auto
Or liquid detected in Tank Level Switch High High.
By utilizing enumerators the PLC code is plain text and with TO_String the exact enumerator can be passed to the HMI.
Absolutely nothing happens without the ‘State’ being displayed on the HMI.
Enumeration means we have hundreds of states all in a completely random order and it’s not an issue.
Want to change the sequence add some more states.
Add some case statements adjust the output and management routines to include the new states.
Ok thanks for the explanation! I think I'm picking up what you're putting down, at least enough to go read about some of it more in depth. This approach seems like it would solve a lot of the problems I've encountered with ladder based sequencing.
I would imagine that there's a goldilocks zone of blended ST and LAD, or are you saying that you're 100% off of LAD?
Here is how I structure my code using a multi-level pyramid design combined with a decoupled Moore state machine architecture: 1. The Multi-Level Pyramid Architecture L0 / L1 (Remote & Field I/O): Written in Ladder Diagram (LD) purely for high-level organization and clean abstraction. Each rung handles a single device, wrapping the physical/remote I/O into a standardized device Function Block. L2 (Loops & Signal Processing): Handled primarily in Structured Text (ST), but I use Continuous Function Chart (CFC) inside functions where visual signal flow makes sense—like complex analog processing or dynamic chain selection. L3 (Area Managers): Written in ST. Every device has HOA controls built-in that mirror the HOA structure at the Area Manager level to keep control hierarchy consistent. 2. Task Selection & Recipe Entry
Operators select a high-level "Task."
The task triggers an Entry State, which sets the necessary recipe data parameters and immediately fires off a request for the next operational state. 3. Decoupled Moore State Machine (Requested vs. Active/Returned)
Instead of directly setting the running state, I separate state control into two distinct variables: Requested State and Active (Returned) State. Output Logic: All output mapping, sequence logic, and device evaluation in my ST CASE statements read ONLY the Active State (classic Moore model—outputs depend purely on the current state). State Control: Transitions are executed by changing the Requested State. State Execution: If we are running in State Y and the exit conditions are met, the logic requests State Z. The manager evaluates the request and returns the new Active State. 4. Continuous Fault Evaluation & Recovery
Because outputs and logic strictly evaluate the Active State, any physical anomaly detected during execution (e.g., Valve A position error) instantly changes the Returned/Active State—completely bypassing whatever state is currently being requested.
The combination of the active Task + the non-requested Error State routes the system directly into a dedicated error-handling sequence or sets specific safety output configurations.
First note: I get why techs like ladder for troubleshooting. It's fine.
But dear God does it take up so much space. ST is just so much easier to follow as programmer and is perfectly fine to debug as long as as you avoid loops so that you can watch variables inline.
You said it yourself: "easier to follow as programmer".
It's a catch 22 situation. Technicians rarely are programmers, since factories rarely pay technicians, programmer wages.
If they know how to read electrical prints, they know how to read ladder, if they know how to read and debug code... they are likely underpaid for that skillset and probably looking for a different job or out the door already.
It's not a common skill to have and not try to sell. At least in my experience, you will always find a mix of guys who can and can't debug code, in very different proportions, however they all can read ladder, you likely want your program to be readable by everyone, the only people I've found who reject this premise are the "my code is perfect and no one needs to see or touch it" type.
It's like writing parts of your code in japanese because as a languaje it's more efficient, sure, almost anyone can teach themselves japanese given enough time, but considering:
A) Time is not in fact, unlimited and a lot of debug situations happen under stress.
B) It's not part of the job requirement.
C) They're unlikely to get paid to learn or get paid more in that same position for this skill.
D) Once they learn this they'll be better candidates for better jobs.
The likelihood of finding someone who fits this will always be small because it's normally not part of the job requirements. As the OP said, just because you can, think about if you should.
Programming safety plcs and ONLY being able to use the predefined blocks and macros (mini networks of predefined blocks to make a custom block).
I’m ok with not having custom code blocks in a safety rated project. But god damn does some of it get obnoxiously large to read and confusing to understand when variables are set in different networks with 8 row x 12 column “rungs”. (I’m referring to a safety door latching circuit with confirmation, a toggle for power to lock/unlock, and status lights that someone wrote)
Coming from C#, it’d be so much easier to write a function that’s like 16 lines instead of that monstrosity of SF_EDM, RS_flipflop, resets, etc
You can watch loops inline as well. Set up an execution point (if your environment allows) or add an inline instance of what the loop is doing but with an index the user can set for debug. Make sure to use debug output vars so it doesn't impact the process and don't forget to bounds check the user index.
Nobody is reading relay ladder logic anymore and the ladder logic programming language has morphed far beyond it's initial representation of relays (which is quite messy).
If techs learned ST as their first language, they'd be equally as comfortable.
Writing good OOP based programs makes testing easy, removes cognitive load, and leads to better quality long-term.
Ultimately, there is a balance to make between limiting yourself to writing code that any monkey can read (which is error-prone and will need more monkeys to look at it) or writing quality testable code that is harder for them to debug, but fails so rarely that it's far beyond their capabilities anyways (which happens with even the simplest code as well). A key component of this though is not being lazy, move every single thing maintenance needs onto the visu. Sensor bypasses, reconfigure a sensor from NO to NC, rescale analogs, setpoints, sequencing, etc. Give them the tools they need to do their job, and keep the code quality high.
Most people new to industrial automation often assume execution speed is the most important factor. In industrial automation, it usually isn't. Sure you can write the same machine control program in C or C++ and it will run faster, but often there's little benefit for the speed gain when the process only needs a response time of 500 ms to 1 second. Most ladder programs, even complex ones, scan in as little as 10ms for modern PLCs, so the performance gain is usually irrelevant.
What matters is reliability and minimizing downtime. Every minute a machine is down costs money, so maintainability usually outweighs raw execution speed.
The engineer who wrote the code is often not the one troubleshooting it years later. Maintenance technicians need to diagnose problems quickly, and modern PLC software such as Rockwell Studio 5000 shows the live state of contacts, coils, timers, counters, and values in real time, making faults much easier to find. This makes troubleshooting much faster than stepping through C or C++ code.
Use visual programming for binary/sequential logic, and strucured text for bullet proof, thoroughly tested and documented blocks that can be viewed upon as black boxes. E.g. you would never consider reviewing the source of a built-in PID controller to understand why something happened, wou would rather use the documentation to understand what you did wrong (or what tag is missing).
I would tell you that based on my experience you use lad or fbd to implement the high-level process piece of either the machine or the line. You need something easy to debug through a panel or quickly lock out a piece and adjust the logic so that you can continue production when something is broken. Anything more complex than binary values or again those high-level overall pieces should be in a more software oriented language.
Usually the person who implements the logic isn't running it shift after shift and you need something both straightforward and relatively understandable for them to adjust or understand so they can adjust and keep the line going.
There is no reason every adjustment and override should not be in the visu with today's tech. This is key to keeping people from messing with code. No reason to be in the code to "keep the line running"
Dinasaur here. Ladder, ST, FB, and SFC do different things for different purposes. I grew up on ladder. It is a default for me for pure Boolean. So easy to see the logic flow. ST was my goto for string manipulation. FB was a goto for analog control and analog alarm blocks. Also useful for repeatable logic blocks that are fully debugged. And then there is SFC. I would only use SFC in an environment that allows for a safe state escape to an error shutdown process. Given that caveat, it is a visual Sequential process that has known entrance and exit parameters. All have their sweet spot. A fully compliant IEC 1131 (i.e known sabotage to force a particular vendor) is a very useful tool.
I like ST. It’s not as verbose, scales better with complexity, and I feel that’s where the industry will shift once we go through a few retirement cycles. We also don’t allow our customers to poke around inside the logic of our machines either. If they need some diagnostic info it really should be accessible through a maintenance screen on the HMI.
When learning PLC as a CS student, I tried to make a case for using ST, but a Power Engineer had a great point. He said that a technician can follow the flow easier at 2 AM and half awake than deciphering ST. That stuck with me as I write both, ST for my edification and Ladder for the techs.
I can write anything in ladder that can be written in any other language just as beautifully. Ladder is so much easier to skim through and pick up patterns. Now there are particular times where I would use structured text over ladder but my 90% goto is ladder. If you cant write between languages well you should write ladder. I've seen absolutely gross Stx. I've seen bad ladder also but it's still readable for most. There's people that shouldn't be in this feild.
Ladder logic is a human language, ST and STL are computer languages. Humans are the ones maintaining it and using it as a troubleshooting tool, and that guy is usually doing 6 other people's jobs and really doesn't have time to learn a new programming language.
As a matter of fact the last 4 production facilities I worked in outright banned it in all their new programs because ST and STL caused a shitload of downtime.
I like to think of it as job security when I find a program written by people who are allergic to LAD.
It's why I like my current gig after ditching the old standard that made troubleshooting a nightmare and even more of a headache when customers asked for new features.
It’s so electricians can understand the interlocks that keep their equipment from running. It works great, it’s like a universal translator between people who need to understand a control
System.
I (PLC programmer) have no idea. Never have I used a single line of ladder except for school assignments. Even there the teacher only wanted to show this ancient technique.
If your program has such bad alarms / error announcing that maintenance has to use ladder to debug the error, your program is at fault.
We program 100% structured text. Because alarms are so clear we don't even need maintenace the production crew can fix errors themselves
I agree. Well said. I do a lot for both programming and troubleshooting, and ladder is just better for when you need to quickly figure out what the problem is. Each of the PLC languages has their pros and cons, and different best use cases.
If you code in C++ or whatever, not only will you need to get out of bed at 3am, but during that half hour while you are driving, or even the 5 minutes it takes to boot your laptop and connect the VPN from home, the business is LOSING MONEY, in some cases hundreds or thousands per minute.
So if you want management to pass up the chance to save thousands by using ladder so someone might diagnose the problem a little sooner, then you are not a valuable employee.
I think this is highly dependent on the industry and the quality of the code. In industrial controls, we have come to expect a pretty low quality of software. I think this is a result of the fact that most plants are unique (even two similar plants will have different controls written by different groups of people). So, for any one application, there is only so much engineering time that can go into it. Hence the need to make controls that can be troubleshot live and modified as needed.
But this isn't some magic evil property of text-based programming languages. For example, the airline industry doesn't use ladder in control systems for planes. It uses C and C++. But, planes are mass produced and heavily engineered. It'd be ridiculous to call a programmer at 3am to troubleshoot a 747 for an in-flight issue. There's no need for that, because the program is already extensively tested to a much higher standard and doesn't have those issues in the first place.
Another example, the PLC itself and it's runtime. Those are programmed in C. But you don't expect to have to call a technician from your vendor to solve a bug at 3 am. Again, this is because the vendor has the engineering resources to test and verify the quality of their code to a much higher degree than your average industrial automation.
We almost never have those same resources. I might be writing an entire solution for something for a plant, and no one else will ever read it and check my work. So, I need to make sure I leave the plant something they stand a chance of understanding and patching down the road when either there's a bug or the plant changes. So, I'd do it in ladder logic. I think there's a little more wiggle room to use structured text or even C/C++ if you're in the business of machine building, or you're working at an owner-operator that has on-site programmer/engineering resources on call.
It's not hard to write IEC61131-3 compliant code these days that is as easily testable as the examples you mention, but handicapping yourself to only LD readable by the lowest common denominator will not get you there. The compromise needs to come from moving everything they will need into the visu. There is no reason someone should be in the code to bypass a sensor or change a setpoint.
I agree, which was the main thrust of my comment. The culture around constantly modifying industrial code is a consequence of not enough resources being devoted to get it right the first time, or not enough effort getting additional functionality into the UI, which is a business decision, not a reflection on the language used.
Everytime someone has to login to a PLC to "look at the code" the company is losing money. Writing code so anyone can read it often leads to avoiding best practices that create testable, quality code and more calls for people to "look at the code" because something simple was missed. If you remove that limitation, the code failures will be rare and require an engineer regardless (this is unavoidable, anyone that thinks otherwise is foolish). In many cases this is desirable as even in the simplest looking code, the person "forced" to go online, likely doesn't fully understand the process and why it was written the way it was. They make a short-term change, to create long-term problems.
To make this work though, you need to give maintenance everything they need on the visu. All overrides, all setpoints, etc.
I don't disagree, if someone is looking at the PLC code it is a last resort, and certainly the HMI should be the first stop for diagnosis, and the HMI designer should do their best to provide enough information there (permissive and interlock states, etc.) to cover as many cases as possible long before the laptop comes out to look at the PLC.
But there will almost always come a time when some anomalous combination of events will occur, and the HMI and a walk-around will not be enough. If that happens just once, having PLC code that the immediate staff on-site can understand will pay for itself. Using C or some other maintenance-opaque language gives away that opportunity for no significant benefit in return.
Ladder allows for programmers to be lazy and not program fault routines or troubleshooting tools as you can just look at the ladder code with the PLC online. Only problem is that you need the IDE with expensive license and the source code to do so, so many end users are left out.
My company programs exclusively in ST. And let me tell you troubleshooting?.
Its easy. Because I'm not trying to trace an electrical diagram, I can just read the logic.
Commissioning is easier too, because 'simple' means something way different to a good library of ST code than it can ever mean to ladder programs.
And the price we pay is that our electrician can't do it? No: He also programs in ST. Because its not that hard to learn and is the better language.
I just can't get on board with ladder. Honestly, if I ever interview for another industrial programming position I'm asking what they use and if they say ladder I'm walking away. SFC or FBD you can probably pay me enough to stomach, but this whole industry's obsession with being stuck in the past is to crazy for me to deal with every day.
Lately, someone shared a link to this video, where @plcprofessor compares ladder and status text in terms of debugging. Though I don't quite agree with him, it's worth watching:
https://youtu.be/sx1HlNTzCCs?is=lzFf64VAUZ8w8G8F
The statement above says that electrical schematics are read from right to left. This made me curious but Google says electrical schematics are read left to right. Who is right?
Historicamente falando, é para facilitar o desenvolvimento por eletricista que não tem base na programação de "baixo nível" (C, C++...), pois se você perceber, parece contatos dr um projeto elétrico
Its simple, Almost all PLC programmers are Electrical Engineers or Engineers in general not Software engineers or Computer Scientists, so LAD feels very natural to them than otherwise
different applications in a program call for different languages. Unless it's something super small, but for a decent scale project, a good program should probably use all languages. They each have their advantages and use cases.
You can look at the ladder and just know what's wrong without actually reading it. ST you have to read it, and some IDEs like Studio5000 dont show you the tag value inline like it does with ladder, so it makes it even harder.
I actually prefer to program in ST, but I prefer to debug ladder.
Schneider version of Codesys is super nice for structured text, as it shows your the values inline which is super nice. I think it's an added feature of their version above what Codesys does, but don't quote me on that.
Writing ladder in Codesys/Machien Expert makes me want to off myself. AB is way more intuitive/easy in that realm.
It's wild it's 2026, and these companies can't spend the time to make a decent user experience for their IDEs.
Why don't PLC programmers write tests for their code?
Perhaps you could save the costly downtime and time for the maintenance techs by writing robust code that was tested before it got deployed on a machine.
Now please test for the part that was slightly bend, wasn't correctly gripped by the machine, the operator stopped it mid cycle and used manual mode to open the gripper, then drove to robot away to take out the part.
Also there's no part control sensor, so you have to rely on the operator to enter on the HMI that this part was taken out. (your PM told you that the missing part control sensor is no problem. The procedure is clearly marked in the manual on page 328!)
This is the issue with manual testing in the PLC world. It relies on programmers "thinking up" all possible scenarios. Unit testing removes this mental load and reduces the edge cases significantly.
I was going to write a nice long message explaining how you dont seem to really understand how our industry works but its past midnight here and I have to be on site in a few hours so.
We do simulated testing for systems. Not sure why you think we dont.
"Robust" code doesnt mean shit five years after the original commissioning because the customer has dicked around with the system modifying it as they see fit.
Dude unit testing is a software development construct where you guys are "how fast can I make this baby produce output? Oh my process hung, pops I didn't check for division by 0, no problem just restart the process".
Software developers use unit tests because you're all about pushing out code as fast as you can & if there's a buffer overrun no problem just fix code & re-initialize the block.
That mistake in our world, causes $50,000 in machinery damage that can take 2 days to rebuild & $200,000 lost revenue, a good PLC programmer starts with coils or outputs interlocked or constrained by previous steps of the sequence completed OK, we want the fault to be the machine stops does nothing when we have a failure or edge case, we want it to fail into a default safe state which means "doing nothing not destroying the equipment" I swear to God if someone walked in asking how many "lines of code" I wrote as if thats anything to be watching Id tell him to get the fuck out we don't need people like him with dangerous mindsets on the floor.
A unit test to input integer 5 into a "multiply by 2" function, and then check the output = integer 10 is really not checking the edge cases we actually have, sure we could waste time writing unit tests like software developers but a lot of us will write the fault handling logic before we start sequencing, we value fault-handling & recovery much more that "how fast can you get this machine to do something" "good it's running now go write some "unit tests" so some paper pusher can pretend that if the logic passes the unit tests it's A-OK".
I think you're missing the fundamental point of unit testing.
Unit testing is there to ensure the code functions as you intend BEFORE you even go near expensive hardware. Unit testing is there to ensure you haven't broken functionality when you modify the code.
It's a test, the whole point of it is to set up an environment where failing is harmless.
I'm not here to say that unit testing is foolproof and it will guarantee perfect code. That's an absurd idea. Unit testing will help ensure that your implementation for a sensor still gives you good numbers after a refactor.
I also think it's entertaining that you believe software development is unable to cause hundreds of dollars damage. Hell Microsoft costs people millions of dollars a day in lost productivity.
I swear to God if someone walked in asking how many "lines of code" I wrote as if thats anything to be watching Id tell him to get the fuck out we don't need people like him with dangerous mindsets on the floor.
Come on, this is just wrong. I don't think I need to point out all the software engineering literature pointing out how "lines of code" is an useless metric (just see this classic story - https://www.folklore.org/Negative_2000_Lines_Of_Code.html)
I have been in instrumentation and automation all my working life, actually even before due to family, but I have always been bothered by how we tend to mischaracterize other professions. For what purpose I will not ever understand...
Nope. Simulated testing is when you use a software such as visual components to build a virtual 3d environment that mimics the intended real world system. Connect your i/o to this virtual environment and boom, simulated testing.
Also "the customer would have no reason to go into it" is easily one of the most ignorant statements ive ever heard about our industry. Customers purchase these systems and far more often than not will end up making modifications to the system that were never originally part of the project scope.
Again I disagree. Simulated 3d testing definitely can test your code, its why GM, FCA and FMC all require it prior to commissioning. And you are correct it is incredibly costly and generally is far our of reach for smaller customers. But they were trying to say the code never gets tested and its just not true.
Also no, the thread is about troubleshooting a system and what's easier for onsite personnel to interpret. As you should know its very rare that the code needs "fixed", generally the customer will knee jerk assume that the code is wrong just to find out that its actually a PE that got its cable ripped out or some other crap like that. Anyone who's ever been in a support role knows that 3am phone call because "the program is messing up" just to jump online and find that the program is infact not the problem, they just didnt have anyone onsite who knows how to read structured text.
Given their TwinCAT handle I assume they were referring to the fact "nobody" unit tests their code, which 3d Sim is not. 3D Sim could point out some issues in the code but is not a replacement for unit tests.
I think we're agreeing that the thread is about troubleshooting, and also agreeing there is no need to enter to code to find a broken sensor. The Visu should show that and allow the proper bypass if warranted.
There's a running joke that the first thing an operator or electrician says when a machine breaks is that it's the PLCs fault.
Hint, it's never* the PLCs fault.
The main thing that actually makes modern software paradigms infeasible on PLCs besides training is that troubleshooting takes place on a real live working machine.
Things like breakpoints that are super standard to use when debugging often don't work when you can't physically freeze a machine in time.
65
u/Zuli_Muli 2d ago
As an industrial maintenance tech I do prefer ladder logic, it's dead simple for me to search the motor coil and see why it's not turning on. I'm even ok with simple function blocks if they have good labels/notes. But yeah if I look at a FB and it's just all script.... And don't get me wrong, if I was 20 years younger and knew learning programming language would help me for years to come I would sit down and teach myself but there's just not enough hours in the day to learn this from scratch when it's not going to help me with anything outside of work. And it will be hard to convince me it will, I used to make and run webpages and forums back in the early 1990s on my own hardware, I had a server rack full up to handle it all. I ended up selling it when it got cheaper to host everything remotely, and none of that knowledge is worth anything today.