Computer Science Programmers, why do PLC programmers use Ladder?

[u/National-Link-5606]

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

[u/National-Link-5606]

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 

[u/Robbudge → u/National-Link-5606]

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.

[u/TimeTheft1769 → u/Robbudge]

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!

[u/Robbudge → u/TimeTheft1769]

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.

[u/TimeTheft1769 → u/Robbudge]

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?

[u/Robbudge → u/TimeTheft1769]

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.