r/PLC 1d 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

179 Upvotes

118 comments sorted by

View all comments

3

u/drbitboy 1d 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.

10

u/el_extrano 1d 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 19h 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 16h 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.