ControlLogix: Ladder vs. Structured Text

[SoftwareJanitor]

With this upcoming project, since I am really a "C"/"C++" programmer and *not* a PLC/Ladder programmer, I would like to use Structured Text for my logic.

So just for the fun of it, I re-wrote a couple of ladder programs here in "C" just to see what they'd look like, and it turned out to be a thousand IF statements with some embedded PIDs and Timers (an oddball-looking program, I'd say).

Anybody here using Structured Text with ControlLogix? Can the entire thing be written in Structured Text, or do you still have to cross over to another model in order to use certain macros?

[dmargineau]

Most of LAD programming instructions are available in ST, however, some are not; if your application requires OSRs, OSFs, TONs, TOFs, RTOs, CTUs, CTDs ( just to name a few), you will also need to implement LAD programming routines in addition to ST.

I/O processing with ST is like commuting to work using a thirty foot mobile home...

[just the cowboy]

If you do it in what you want, maintenance and production will hate you. In a real life troubleshooting world 1000's of IF statements will make your head spin. A ladder that is broken down to a area of machine will make it easy to troubleshoot. That is why they are so widely used, ST is great for a complex TASK, but thats about it.

[RET]

Only fairly involved math operations that require several steps. Other than that, no.

Probably good idea if you're in integrator/contractor and your trying to obfuscate your code to ensure call backs and more billable hours from a customer (not that it can't be done in ladder). But either way, after that you'd be on my blacklist.

[Phrog30]

Some of the worst PLC programs I've seen were written from "true" programmers. Most plant personnel will not understand anything but ladder. Perhaps you are good at c programming, but there is a trick to ladder and it really only comes with experience. Just remember the customer in whatever you choose.

[Lynx777]

I have never programmed in structured text, though I've done troubleshooting and rework with quite a few programs that have it. In my experience there is always a mix of text and ladder in a program. I've been told by a couple of programmers that I know that use structured text, that you "can" do the whole thing in text, but it's easier to go with ladder for some things.

From my viewpoint, (as the guy that normally comes in later on to repair or modify the original equipment) if I saw that the entire program was done in structured text, you would be able to hear me cussing from five miles away. That's just my opinion though.

[nhatsen]

Originally Posted by dmargineau

... if your application requires OSRs, OSFs, TONs, TOFs, RTOs, CTUs, CTDs ( just to name a few), you will also need to implement LAD programming routines in addition to ST.

Those instructions have an equivalent on ST:

OSR -> OSRI
OSF -> OSFI
TON -> TONR
TOF -> TOFR
RTO -> RTOR

[dmargineau]

Originally Posted by nhatsen

Those instructions have an equivalent on ST:

OSR -> OSRI
OSF -> OSFI
TON -> TONR
TOF -> TOFR
RTO -> RTOR

They are not equivalent; you could use them to achieve similar results, however, functionality and "handling" differ.

[Paully's5.0]

The problem is that the OP doesn't know the Logix platform very well at all, and is starting from scratch on a rather large project resulting in a non-traditional approach.

ST has it's place, and for the fun of it I've taken logic used previously done in ladder on a ControlLogix for use in batching and re-did a lot of it in ST. The objective was to learn a bit of Codesys, in which I decided the ladder editor on that platform wasn't great so I decided what the hell, learn some Codesys and mess around more with ST.

Because of my experience in this area, and having good structured methods to begin with applying that knowledge to ST came pretty easily, I did have some challenges but I did find some advantages too it, which was more due to the Codesys platform. Primarily the ST editor is much nicer and I could define a simple function (No Logix equivalent) rather than function block (AOI). I even built in an equivalent to the Logix "Phase Manager" functionality. I was actually pretty surprised, the ST logic is pretty "clean" however this was due to already working from established standards and methods of handling large process systems.

So yes, it can be done. But be prepared for being responsible for this 100% even 1-2-5yrs after the fact.

[James Mcquade]

this is what I would do.

See what programs are on the plant floor - ladder versus structured text.
find out how many maintenance guys know structured text and are comfortable with trouble shooting.

see what the company specification and requirements are for programs.
get with management, engineering, and maintenance and get an agreement on how to proceed.

if they say ladder, ladder it is.
if they want structured text, then st it is, and if no one in maintenance can work on it, and production suffers, everyone in the meeting gets the blame, not just you. BUT, you will be the one getting all the calls!

Remember, maintenance can be your best friend or your worst nightmare!
you can't just throw something at them and expect them to work on it, you need to work with them and explain things.

james

[ASF]

I have customers that outright ban ST in their procurement specification.

I have other customers that will accept ST as long as the price your company is quoting includes 24/7 remote troubleshooting support for 5-10 years after the machine is purchased for any issues that can't be immediately diagnosed using the HMI.

I have customers that couldn't care less what language you program your machine in, as long as it works.

I have customers that will have their technicians review your code as soon as you hand over the job, and if it's poorly written (no matter what language you chose), your company will not be favourably looked upon for the next round of tenders.

The common theme here is that it makes no difference what I like doing inside my PLC, I do what the customer wants. They're the ones paying me to do it, and if they don't like what I'm doing, they don't have to pay me.

If your customer will accept ST, and the resulting ST code is clear, concise, and easy to follow for a suitably skilled maintenance technician (who I can almost promise you, will not be a C++ programmer), then go for your life. If not, you'd have to spend a long time convincing me that it's a good idea.

Also:

Originally Posted by dmargineau

I/O processing with ST is like commuting to work using a thirty foot mobile home...

This just made my morning

[Epy]

Originally Posted by Phrog30

Some of the worst PLC programs I've seen were written from "true" programmers. Most plant personnel will not understand anything but ladder. Perhaps you are good at c programming, but there is a trick to ladder and it really only comes with experience. Just remember the customer in whatever you choose.

Some of the worst programming I've ever seen was from "good" PLC programmers. Don't know how many times I've seen people either use LBL/JMP loops or actually write out the individual COPs/MOVs when they have to shift arrays.

I think your strategy depends on your industry. There are some places where it is expected that the customer's employees will tinker in your program. In others, such as OEM, it's the complete opposite. You don't want to make it easy for people to tinker in your program in the first place.

[Phrog30]

Originally Posted by Epy

Some of the worst programming I've ever seen was from "good" PLC programmers. Don't know how many times I've seen people either use LBL/JMP loops or actually write out the individual COPs/MOVs when they have to shift arrays.

I think your strategy depends on your industry. There are some places where it is expected that the customer's employees will tinker in your program. In others, such as OEM, it's the complete opposite. You don't want to make it easy for people to tinker in your program in the first place.

Not that you will care, but not much I agree with in your post. So using lbl/jmp is not good practice? That's ridiculous. Intentionally making a program complicated to prevent tinkering is even more stupid. You don't want tinkering, try a password.

[LadderLogic]

I should say that in my experience "jumping" the regular program scan order is considered in the PLC world just as bad practice as using GO TO statement used to be considered in Basic, Visual Basic etc. Each has its use but better to be avoided for clarity.

Modern PLC processors are typically fast enough so not to worry about the execution times and not to skip sections of the code with jumps. Just my two cents.

[Phrog30]

Originally Posted by LadderLogic

I should say that in my experience "jumping" the regular program scan order is considered in the PLC world just as bad practice as using GO TO statement used to be considered in Basic, Visual Basic etc. Each has its use but better to be avoided for clarity.

Modern PLC processors are typically fast enough so not to worry about the execution times and not to skip sections of the code with jumps. Just my two cents.

If I want to create a loop in ladder I will use a jmp/lbl. So, let me guess, looping is bad practice?