When I was in college, I interned with a great German industrial automation company. I specifically remember that the programming environment we sold to customers included support for "condition-coil" logic, AKA "ladder logic." Basically just simulated relays.
For controls guys who had dealt with relays for most of their professional lives, that relay-oriented logic flow made sense. A typical computer science student's idea of boolean logic gates and procedural control flow just wasn't part of their lexicon.
We also offered a graphical, procedural programming language (imagine Scratch except it controls part of a factory). You could teach it to them, and they'd understand it, but many of them never used it. They just wanted relays.
> I specifically remember that the programming environment we sold to customers included support for "condition-coil" logic, AKA "ladder logic."
Yes, the IEC 61131 languages. AWL is a crippled assembler language, ST is a crippled Pascal.
Industrial automation is for masochists. The usual explanation is that the PLCs need to be programmed by electricians without any college degree, but (a) are electricians not stupid and (b) would better languages not need to be more complicated.
It was so much worse before 61131. My career in industrial automation was on PLCs that predate 61131's existence and had no structured text language of any kind. Ladder only. I helped write a toolchain that compiles languages similar to 61131 (but, again, predating it) down to ladder. I've seen an implementation of bitwise floating-point math in ladder that no mortal human could possibly understand.
Our experience was not that companies think electricians are stupid, but that they're electricians: they know electrical stuff, not computer programming. A ladder diagram is immediately recognizable to an electrician or technician who needs to diagnose an equipment failure and wasn't involved in writing the program.
61131! I haven't thought about that number in years. Couldn't agree with your evaluation more. The sad thing about ST is that it was probably the least shitty of the IEC 61131 languages.
Despite the masochism, it was a fun field to work in for a time. Since the industry demands these shitty esoteric programming languages, you end up with all these small companies writing their own compilers and runtimes. It's a unique opportunity to do real-life compiler development from the ground up.
61131 has ladder logic, function block, and structured text, which is a pretty eclectic group of programming representations. I think about 99% of the PLC programs I saw were ladder logic, with the exceptions being Siemens pushing structured text with a C-like look-and-feel.
Anywho, cool, robust, reliable things still got made, you just had to think differently. It was very interesting to think about those programs and their relative programming simplicity when compared to complex, modern C++ that is running in other codebases I've seen since then.
I wonder what a better language would look like. It would have to be similarly locked down, because trusting a programmer with a full strength language seems like a bad idea when it's something that could kill people if it fails.
For anyone interested in trying out ladder logic, I run a web app that includes a ladder logic simulator in the browser. There is a small set of lessons too.
Sorry it’s desktop only for now. I never got around to figuring out how to make the drag and drop interface work well on mobile screens, although I’d love to.
> For controls guys who had dealt with relays for most of their professional lives, that relay-oriented logic flow made sense.
Ladder logic is based on ladder control schematics. They were used for machine control circuits to present the circuit as a series of rungs running from left to right, the left side representing a connection to the control power supply hot or positive line and the right represented the control power supply return or negative. Each rung is a circuit that handles some logic. eg you have a laser machine with three doors and two access panels each holding a normally open switch closed to complete the circuit - when all the doors are closed the output is signal is high which you can use to ensure the doors are closed so no one gets melted. The sequence reads top to bottom so when you trouble shoot you walk down the steps checking each right hand output device and if it didn't work, work your ways backwards through the rung with a volt meter.
Way back I got to fix an old Marvell power feed metal cutting band saw. All relay logic and the saw would run one cycle, retract and do nothing. So I grabbed a meter and the ladder diagram and worked my way down until I found a rung with no output. Turns out the saw carriage return limit switch bracket came loose and the return switch was never pressed which would reset another rung to restart the cycle again.
> A typical computer science student's idea of boolean logic gates and procedural control flow just wasn't part of their lexicon.
Nonsense. I was exposed to industrial automation in high school where I was preparing to become an electrician via a robotic manufacturing system from eshed robotec. I really liked computers but was never interested in programming them at that point even though I knew some gw basic and the robots were programmed in basic. Then I wound up taking an AP c++ programming class and it clicked.
To me ladder is a great language and perfect for representing the boolean data flow through sensors and switches to visually group functions into rungs. It's so much faster to visually parse a rung vs a block of text. It's the default on every controller for a reason.
Though I'll say this: automation software sucks shit through a straw. So much of it was designed on Windows while riding the 90s OOP hype train. And the design by committee with languages and standards baked into iec/iso standards is depressing. 61131-3 defines a crappy Pascal like language called "structured text" but everyone bolts on their own oop extensions to the language in various proprietary ways. And you don't want to begin to fuck with the absolute dog shit Byzantine garbage fires that are PLC IDEs. They're so invasive that everyone in the biz runs then in VMs so they don't bork the OS.
Another thing to note is that, depending on the standards (e.g. NFPA vs IEC), your control diagrams would be in horizontal [0] or vertical [1] format. So the typical left-right ladder flow you might see in RSLogix or something worked really well with drawings produced to NFPA standards, but the mapping broke when given "waterfall"-like schematics from a European shop.
You are 100% correct about the tooling being crap and ladder representation being useful as a visual mapping.
Ladder is completely unknown in most of Europe. I think it's mostly ST (structured text) followed by fbd (function block diagram) or sfc (sequential flow chart).
I'm not against st or c or whatever, I've done control programs in all of them. To me, Debugging ladder is awesome as most IDEs give you a live view of the io state and it's great to sit the laptop or computer cart by the machine and begin pressing switches and wiggling wiring/connectors to see what is not working and the ladder contacts light up when they go high. Simple fast visual debugging.
We've incorporated some flow chart and ladder like io debug screens on our hmi's. Pop open the debug screen and see what isn't on and the association of inputs and the output condition they set. Mostly eliminates the need to drag around the computer.
For controls guys who had dealt with relays for most of their professional lives, that relay-oriented logic flow made sense. A typical computer science student's idea of boolean logic gates and procedural control flow just wasn't part of their lexicon.
We also offered a graphical, procedural programming language (imagine Scratch except it controls part of a factory). You could teach it to them, and they'd understand it, but many of them never used it. They just wanted relays.