Which programming method is better - ladder logic or structured text

[jazzman44]

Well said , Tom I totally agree

 

[FactoryTalktotheHand]

I agree with Tom. I think too many programmers fail to realize one important fact of life: one day, eventually, someone else will need to look at your code. Nothing drives a troubleshooter up the wall more than a show-off programmer. Yes, you clearly know how indirect addressing works. Bravo for you. Show-off programmers are like those people with a word-of-the-day calendar, except they must have an "instruction of the day" calendar. Like "today I'm going to map my I/O using nothing but COP instructions and do it a word at a time!" or "today I'm going to use a sequencer to turn this motor on and off!"

Now, I can understand what you're doing, and I can work around it, but when I see code described as "fancy" and "elegant," everything in my gut tells me it's actually a huge pain in the &*^ to troubleshoot, because 999 times out of 1,000, it is. Most of the people looking at PLC code aren't people familiar with plain-language style programming. This is why PLCs were invented to begin with. GM could have easily hooked up a computer of the era to inputs and outputs and ran their plants, but they would also have to have an army of people with very specialized knowledge maintaining operations. The entire point of a PLC is to have an automated system that a non-programmer can understand and troubleshoot.

Ladder does have it's strengths and weaknesses. It's major strength is troubleshooting ease. You can look at a graphical representation of the "circuit" and see why exactly the output isn't turning on. That's powerful. However, ladder isn't so good for sequential operations or manipulating large arrays of data. ST makes more sense for that, but again, most people troubleshooting a PLC don't understand ST, they understand Ladder.

 

[Paullys50]

Always humored by some of the arguments I see about one versus another...

At the end of the day, I want a program that has good STRUCTURE. Whether that is in Ladder, ST, FBD... it really doesn't matter. Any program with good structure is better then another with poor structure.

As for programming for the end user...KISS..., do that an chances are you won't get the project, or the end product will look cheap or will miss critical features especially in the alarming/diagnostic department. It simply costs to much $$$ to program to the lowest denominator and the customer certainly won't pay for it. On simple machines/process' where 'brute force' programming can be done and achieve the end goal...by all means have at it in ladder and follow KISS. Any large complex process', well the thing has to work, has to be reliable and as to be PROFITABLE for the SI/OEM. Oh, and it also has to be CHEAP enough to win the contract. Be aware that most projects in the bidding phase end up having to cut 10%-25% or more in final negotiations to win the project to begin with, you have to make it up somehow. Not to mention the scope creep that always happens and the customer's unwillingness to pay for change orders. The SI/OEMs need to make money too.

I have seen over-the-top-programming as well, more often than not after I get over the initial 'what is this ****' moment, I realize my place in the world of automation, and most likely there was a reason for it. If I don't understand that reason, doesn't mean it's wrong or poor practice. Usually it's justifiable, sometimes it's just the programmer trying to prove how smart they are, sometimes it's because the programmer didn't know what they were doing.

I've had this discussion with many maintenance people, and once I tell them the 'facts' of the project - "This was originally quoted for $500,000...then in negotiations it was cut to $400,000 and over the course of the project things changed, so here it is." They suddenly realize they've got the short end of the stick due to the higher-ups of their company trying to save $$$ than the SI/OEM trying to be fancy.