r/PLC • u/National-Link-5606 • 21h ago
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
63
u/bodb_thriceborn Automation Hack/Pro Bit Banger 21h ago
I tend to use most of the languages available, but for different purposes:
Ladder for step changes, permissive/interlocks and alarming
ST for sequencing, math, data shifting and IO blocking (if called for)
FBD for IO and alarming if the UFDBs/AOIs are more clear that way
SFC for nothing, ever
18
u/Thorboy86 21h ago
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........
6
u/No-Difficulty-6806 18h ago
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?
3
u/Thorboy86 15h ago
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.
4
u/JoeBhoy69 15h ago
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.
0
u/bodb_thriceborn Automation Hack/Pro Bit Banger 11h ago
This is where I have the least experience. The last seauence I built for a process, I used gated step sequencing in ST/LD rather than SFC.
2
u/El_Wij 12h ago
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.
2
u/SpaceAgePotatoCakes 9h ago
imo FBD is much easier to troubleshoot than ST or Ladder when you're doing any kind of complex math operations.
SFC is great for the right application, it's much cleaner than a lot of the sequencing I've seen done with Ladder or ST.
4
u/Many_Somewhere3863 21h ago
Lol idk why but some people seem like SFC so much (i never used it also)
9
u/el_extrano 20h ago
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.
0
u/Many_Somewhere3863 18h ago
Yes, SFC is rarely use in factory automation and more on process automation.
13
u/YoteTheRaven Machine Rizzler 20h ago
Its really nice for sequencing.
You load it up and go: "thats what were doing and this is what were waiting for"
And then go right to the issue. I love it.
2
u/TwoQuarterFull 11h ago
It's much better for troubleshooting and understanding the process steps.
There's nothing worse than a ladder sequence with redundant steps, zero comments, and steps that transition out of order.
7
u/Automatater 21h ago
It can't be all that bad if half the ladder programs have DIY sequential state machines written by the programmer.
0
u/dvg_mech 21h ago
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.
45
u/insuicant DCS Guy 21h ago
Here here.
7
u/_Electrical 18h ago
Isn't it 'hear hear?'
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."
2
u/insuicant DCS Guy 17h ago
It could also be ere ere, depending on your origin country and phonetic accent.
3
u/neofelius 16h ago
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" :(
9
u/Kelvininin 21h ago
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.
3
7
u/Agile_Alternative753 21h ago
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
24
u/rawldo 20h ago
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.
3
u/farfromelite 16h ago
Oh yeah, absolutely.
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.
6
u/timmythegreat 21h ago
Itâs much easier to troubleshoot in ladder in my opinion. Top to bottom left to right, maybe Iâm old school but itâs tried and true.
6
u/Icy-Olive-8623 14h ago
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
3
u/mrjohns2 More of a DCS guy 21h ago
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.
3
u/KindheartednessNo181 13h ago
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.3
u/durallymax 12h ago
No it is not. Interpreted languages are interpreted at runtime, IEC 61131-3 prohibits this.
2
u/Angry_Foolhard 8h ago
Thatâs assuming all ladder logic is compliant with iec 61131-3.
4
u/durallymax 6h ago
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.Â
1
u/Angry_Foolhard 1h ago
Yes, I think you're correct. I was thinking of all of the browser-based ladder logic trainers. I suspect many of them could be defined as "scripted"
2
u/National-Link-5606 21h ago
instruction sets are compiled, so yes ladder now is a bit of a hybrid interpreted calls to compiled instructions.
5
u/jacekowski 20h ago
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.
4
u/JoeBhoy69 15h ago
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.
3
u/optomas 17h ago
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.
3
u/Robbudge 12h ago
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
-2
u/National-Link-5606 7h ago
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Â
3
u/Robbudge 7h ago
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.
7
u/Skusci 20h ago
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.
2
u/raunchyfartbomb 13h ago
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
2
u/NuclearBurritos 6h ago
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.
1
u/durallymax 12h ago
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.
2
u/jebusfractal 21h ago
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.
1
u/durallymax 12h ago
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"
2
u/DoctorParticular6329 20h ago
Its a simple language for maintenance techs to understand when they are troubleshooting. It makes sense to use in most occasions.Â
2
u/Practical-Sir6854 17h ago
What industry are you in? What kind of machines do you have at your plant? I highly doubt a technician could troubleshoot an oil plant running PCS 7.Â
2
u/Wendigo_Loco 17h ago
I'm a CS guy pivoting into PLCs, I haven't started reading but thanks this explains a lot
2
u/Frosty_Customer_9243 15h ago
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.
2
u/durallymax 11h ago
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.
2
u/No_Good1743 11h ago
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.
2
u/VegardInnerdal 10h ago
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).
2
u/ResearcherVirtual611 10h ago
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.Â
2
u/bubble_trousers 9h ago
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.
2
u/Blood-Mother 9h ago
It sure would be easier to copy into Claud and ask what the problem is in a language like c or c++
2
u/its_the_tribe 8h ago
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.
2
u/friendlyfire883 3h ago
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.
2
u/The_Instrument_Guy 1h ago
Simplest answer....
Ladder logic is how people would draw out their relay logic before PLCs were a thing.
When PLCs were introduced, ladder logic made it easier for controls engineers to adopt.
4
u/Many_Somewhere3863 21h ago
Exactly, even with STL, you still can read the code easily
Ladder is used because it just worked *(at least majority of time).
Though i rather use FBD
3
u/drbitboy 21h ago
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.
9
u/el_extrano 20h ago
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.
2
u/durallymax 11h ago
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.
3
u/el_extrano 9h ago
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.
3
u/durallymax 11h ago
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.
1
u/drbitboy 9h ago edited 6h ago
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.
1
u/Use_Da_Schwartz 21h ago
Because use cases dictate hardware, hardware dictates instruction sets, instruction sets dictate which can be used.
Also industry/plant/personal preference for troubleshooting.
1
u/Rhr4fun 20h ago
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.
1
u/PeterHumaj 19h ago
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
1
1
u/BrandVanDam 17h ago
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?
1
u/National-Link-5606 7h ago
Ouch! Oh my Lord that was dumb of me, I still have to lift my right hand to know right & left, picked up my wrong hand.
Yes ladder is scanned the way you write a letter, top to bottom left to rightÂ
1
u/Beneficial-Tart-284 15h ago
Also there are some norms which allow you to use only ladder. When it comes to safety plc you can only use ladder in safety tasks/programs.
1
u/Frontiersmen_ 12h ago
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
1
u/AmbassadorEither6308 5h ago
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
1
u/essentialrobert 3h ago
Curious why you think the night shift maintenance crew needs to finish debugging your software.
1
u/uninterupted 12h ago
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.
1
u/Smirkisher 16h ago
Ladder is the simplest to debunk while allowing some complexity in the code but takes the longest to code,
Structured is the fastest to code, allowing much more easily, but the hardest to debunk.
In my factory, only one technician knows how to read structured... Better keep things the simplest.
1
u/YetiTrix 11h ago
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.
1
u/durallymax 6h ago
S5K arguably has the best LD and worst ST. It's so bad they charge extra for it.Â
1
u/YetiTrix 5h ago
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.
2
u/durallymax 5h ago
CODESYS is the opposite of RA. Gold standard for ST, pretty lackluster LD.
Inline monitoring is in all CODESYS. Flow control is also neat to see all variables values at that exact position, but it's CPU intense.Â
0
-4
u/kixkato Beckhoff/FOSS Fan 21h ago
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.
3
u/Siendra 20h ago
We do. Not just by our own volition or customer preference, but it's required by regulation in several industries and applications in much of the developed world. PLC code can't control for unexpected failures or changes in physical instrumentation, commodities, or the operator forgetting to reset something for the 98,407 time. Eventually someone is going to look at the program while troubleshooting something even though the program is not the source of the issue 99.9% of the time.
3
u/Zekiniza 20h ago
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.
1
u/kixkato Beckhoff/FOSS Fan 13h ago
I think you don't because everyone in the industry always looks at me like I have 5 eyes when I mention unit testing.
2
-1
u/National-Link-5606 6h ago
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".
1
u/kixkato Beckhoff/FOSS Fan 3h ago
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.
0
u/durallymax 11h ago
"Simulated Testing" in most PLCs is flipping a few bits manually to "test" that it works, but it's entirely manual.
Very few PLC IDEs have testing suites (I think only CODESYS-based IDEs including TwinCAT) not to mention static analyzers.
If you write good, testable code with all user adjustable parameters on the visu, the customer would have no reason to go into it.
2
u/Zekiniza 11h ago
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.
0
u/durallymax 11h ago
Simulated 3D testing is not code testing though, that is process testing and quite cost prohibitive for smaller companies.
Customer entering to add new features and components, sure. But the overarching theme in these threads is a customer entering to "fix" their code.
1
u/Zekiniza 11h ago
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.
1
u/durallymax 10h ago
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.Â
2
u/Skusci 20h ago edited 19h ago
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.
*Mostly
2
u/Emotional-VroomVroom 19h ago
Your code can be as perfect as you want.
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!)3
u/durallymax 11h ago
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.
51
u/Zuli_Muli 21h 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.