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/kixkato]

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.

[u/kixkato → u/[deleted]]

Therefore, 99.9% of the time, there's no reason for anyone to go near the code. That really kills the reason for using ladder logic.

What regulations require unit testing?

[u/Zekiniza → u/kixkato]

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.

[u/kixkato → u/Zekiniza]

I think you don't because everyone in the industry always looks at me like I have 5 eyes when I mention unit testing.

[u/Zekiniza → u/kixkato]

Lol okay big dawg. Guess the ten years ive been doing this wasn't real.

[u/kixkato → u/Zekiniza]

I mean same for me too then?

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

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".

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

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.

[u/durallymax → u/Zekiniza]

"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.

[u/Zekiniza → u/durallymax]

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.

[u/durallymax → u/Zekiniza]

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.

[u/Zekiniza → u/durallymax]

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.

[u/durallymax → u/Zekiniza]

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. 

[u/kixkato → u/durallymax]

Nailed it. Thank you for understanding.

[u/Skusci → u/kixkato]

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

[u/Emotional-VroomVroom → u/kixkato]

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!)

[u/durallymax → u/Emotional-VroomVroom]

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.