ControlLogix: Ladder vs. Structured Text

You guys are going round and round arguing when you don't have the facts.
What is the application? If it requires a lot of computations as in some motion control applications then ST is definitely the right language. However, I would use ST in SFC or some state machine.

We use a state machine and ST for our programming. On top of that we have a log that PLCs don't have. Much also depends on the implementation too. There are few ladder editors that I like. Most are garbage compared to Microsoft's Visual Studio. Some PLC editors are so bad they designers must have been brain dead.

The fact that there are people that don't understand ST may be a good thing. Much of the time you don't want people screwing with the code.

From a developer's standpoint it is better to have a way for the customers to change parameter on an HMI rather than screw with the code.

It is possible for the ST compiler to know the row and column of every variable, matched parentheses, expressions and blocks of code on the screen and high light them with they are active but usually ST executes quickly so things would turn on and off too quickly. Good compilers should know the location of every section of code so it can be high lighted when there is a syntax error or fault.
 
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?

Depends... If you give the customer your source code, then try to find a happy medium between what their tech's can troubleshoot and what you can use to produce a quality product on time.

If you don't give the customer your source code, use whatever is easiest for you/your company to support.
 
You guys are going round and round arguing when you don't have the facts.
What is the application? If it requires a lot of computations as in some motion control applications then ST is definitely the right language. However, I would use ST in SFC or some state machine.


OP has posted about the project in a previous thread

Given the information provided about the project and the lack of experience the OP has with the platforms, it's very hard to support some of the thinking here. IMHO it should be farmed out to a competent SI. Way too much risk.
 
Wow! I LOVE getting these kinds of enthusiastic responses. And just to show my appreciation, I'm going to try to reply to all of you!

dmargineau:
===========

You had cited some Ladder (LD) instructions not available in Structured Text (ST). But then 'nhatsen' seemed to refute that, listing ST equivalents. You replied that the structured text instructions were "not equivalent", but could "achieve similar results". How do you square those two statements? Aren't they equivalent if they achieve similar results? The goal is to write a program that performs a specified function, right?

Also, later in the thread, you said programming instructions are "conveying information/commands from the user to the operating system of the automation controller". This is not true in a conventional computer (maybe PLCs are different, I don't know). Typically, the instructions (in whatever language you are using) are compiled down to assembly instructions (where you can see the individual native CPU registers selected to execute each instruction). Below even *that* are the machine-level instructions (that you never see), which execute at the 'microprogram' level, driving the actual hardware to move data to/from memory and in/out of the processor registers.
The Operating System is just another piece of software that runs at the Executive (or Privileged) level to manage multiple "Task" level applications, giving them CPU control or executing privileged-level instructions on their behalf (amongst other things).

just the cowboy:
===============

It turns out, that at this facility at least, Maintenance and Production *never* look at programming software. Neither have access, know where anything is, and have never even *tried* to feign interest. Now, it's possible that could change someday. Never is a long time. But I have to admit - I've never written logic for someone else who wasn't also an engineer or someone who would understand.

RET:
====

This is an in-house (OEM) project, so no contractor issue here. But if I *was* a contractor, I would do whatever the customer wanted ... for obvious reasons.

Phrog30:
========

See RET response above. And with regards to your tiff with Epy ... I *never* write 'complicated' code. Every programmer should strive to write logic that balances clarity with efficiency. And that includes good documentation that describes WHY something is being done (instead of WHAT). Structured Text allows for free-form endline comments, which I hold dear to my heart. The commenting model in ladder leaves a LOT to be desired, IMO.

Also - it IS, in fact, considered bad programming practice to use JUMP-to-LABEL type structures in your logic (aka "GOTO"). I was trained on this right out of college on my first project by a senior software engineer. Not entirely sure WHY ... because the compiler will generate a JMP-to-label on its own anyway (for any loop). I think it's just considered bad style. And all these years, I've *never* used a GOTO statement in any program I've ever written.

Lynx777:
========

Well, Structured Text is fairly new to the Industrial Controls programming world, and with Ladder so firmly entrenched already for years, that's pretty much what most programmers in this industry know and are used to. And if you don't see a compelling reason to change to another model, I can understand the negative reaction to coming across it. Probably thinking ... 'oh c'mon ... why did this guy use Structured Text when 99% of programs are written in Ladder?"

nhatsen:
========

Nice job pointing out those equivalent Structured Text instructions. I get the impression here that Structured Text is not fully understood, or hasn't *really* been properly compared to Ladder because most Ladder programmers don't see a reason to change to it. And I can understand that. If what you have is working for you, why change it up, right?

Paully's5.0:
============

You're right. No ControlLogix experience, very very little PLC coding (2 or 3 apps years ago), no love for Ladder, so I'm looking to leverage what I prefer to do with what the platform allows. When it gets turned over to someone else, they'll just have to learn it. It's not like this is a one-of-a-kind programming language. "C" is very well known in the programming world, and more and more 'conventional' programmers must be entering this Industrial Controls field (or Rockwell is trying to attract them) ... otherwise why would Rockwell go to the trouble of adding that language to their programming IDE?

Also, regarding looping in logic, it's done everywhere, in every program, whether you program it in or not. If you call a subroutine, the compiler will generate an instruction to load a register with the address of the next instruction, then generate a jump to a label where your subroutine is. When the subroutine completes, the compiler will restore the Program Counter with the saved address and jump back. Not sure exactly *what* PLCs do with a FOR instruction, but it *looks* inefficient to me in that it performs repeated subroutine calls, which has the overhead I mentioned above (and is therefore slow-er). Now maybe PLCs have more onboard registers to handle this more efficiently, I don't know. Never seen any internal architecture of PLC hardware.

As for "farming out" this project. I'm pretty sure I can handle this program, however, I will be fighting with the idiosynchrasies and weirdisms of Rockwell, so that's going to slow me down a bit. Let me program this on a platform I want, and it's a piece of cake.

James Mcquade:
==============

About 100 PLC apps here. All Ladder. Mostly Allen-Bradley, some GE, a few outliers on skids, but most are not changed or touched much (or if at all).

No specs/preference here for any particular programming platform. Management will let me do whatever I want. They don't care. Just make it work. No maintenance involvement whatsoever here. Automation is the sole owner.

ASF:
====

As I stated above. This is "in-house" project, no contractor. And I'll say it again - nobody should be looking at these programs who doesn't understand programming. And it they *DO* understand programming, then they can adjust to learning something new, which we all have to do from time to time.

Epy:
====

I don't write programs to be unreadable by others. Just the opposite. That's how I was trained coming out of college. Clean and clearly-written source code. Personally, I think Ladder is the worst programming model I've ever seen. But maybe I haven't seen good Ladder logic, either. I just *hate* looking at Ladder logic and seeing rungs serpentine around and around ... to me, that's very hard to look at. I also tend to see a LOT of repeated logic on rungs, but maybe that's just bad Ladder Logic programming, I don't know. And the commenting is lousy. You've got those same tag names popping up all the time ... and you can add rung comments, but it's just not the same as end-line comments in "C". Ladder programs seem to go on and on for 700, 800, 1000 rungs, and I just look at all that and I say ... I betcha I could write this much more efficiently, and you'd be able to read it much more clearly, in Structured Text. You could also print it out very neatly and read it like a book. Ladder is a hodgepodge of intermingled constructs. It started out as a good idea, but then it was extended, but without breaking free of that "Power Rail" model. I just don't care for it at all. It really looks like something that was extended and extended and extended until someone realized it couldn't continue like that ... and so Structured Text was introduced.
 
You could also print it out very neatly and read it like a book. Ladder is a hodgepodge of intermingled constructs. It started out as a good idea, but then it was extended, but without breaking free of that "Power Rail" model. I just don't care for it at all. It really looks like something that was extended and extended and extended until someone realized it couldn't continue like that ... and so Structured Text was introduced.

As a computer programmer you might understand my view that ladder is like visual assembly language. :ROFLMAO:

Also, good ladder projects are generally broken down into manageable pieces (files) like a modular C program. If you are looking at files with 100's of rungs it's almost guaranteed that you are looking at not-good practice. I remember the first ladder program I made (which was done by copying hand written ladder logic from paper that someone else had created) was about 900 rungs in one file. They didn't send me to school so I didn't know you could break the stuff up. I was very happy when I figured that one out.
 
Also, later in the thread, you said programming instructions are "conveying information/commands from the user to the operating system of the automation controller". This is not true in a conventional computer (maybe PLCs are different, I don't know).

You didn't; maybe you do now; PLCs are not Windows or MAC machines; they are trying Linux as we "speak"; we'll see...

The Operating System is just another piece of software...

Controller OS is referred to as firmware in the automation world; the user software is exactly what I have stated above; you see, that's why they are referred to differently...Because they are not the same fruit...:D
 
Try switching font to consolas and zooming out in LD.
Also get rid of all the toolbars and controller organiser. Press the shortcut key if you need to bring up controller organiser.
Also change the background colour of rung comments so they stand out as different to tag names.

Then use ST, because you can probably write betterST than LD given your background.

Sometimes we write some pretty horrible routines in ladder, when it would have looked neater in ST. Think of it as writing an entire suite of software in Java, rather than switching between Java Python C C++ C# depending on which developer is in that day, or which language produces the neatest result for that particular subroutine. Sure, any decent programmer can handle it, but what about the new guy? What about that person I become at 3:15am on my 7th day of commissioning? (That guy is rubbish at ST, unlike my regular self)
 
Don't confuse jmp/lbl with GOTO. I use jmp/lbl in ladder as a for loop. And sorry, jmp/lbl is not bad practice. Writing bad code is bad practice and you can write bad code with "good practice instructions". As you said, you have seen rungs wrap, poorly documented, bad flow, etc. There are a lot of guys that write PLC programs that shouldn't. But, a lot of guys do it because it's relatively easy. Ladder logic's target audience was the electrician used to relay logic. The learning curve from relay logic to ladder was minimal. It has remained because it's easy, and it works. Again, I write my code not for me, but for the customer. While you might not like ladder, there's a good chance the majority of your customers do. Like I said, think of them, not yourself when writing your programs.
 
Imagine a company where a bunch of people work. Each person has a job to do and has to work with others to accomplish the overall goal of the company.

The company has an organization that is suitable to what they are trying to accomplish. The people working there have different jobs, some are workers, experts, managers for instance.

Who is going to do what and how things are done is very important. Even with the best people in the world a dysfunctional organization will ruin everything.

If we would try to explain to a new employee what we want him or her to do we would want to be very clear and not overly complicate things. Obviously complex jobs have complex job descriptions but there usually a lot of jobs that are pretty straight forward.

A program works the same way as a company. It's structure is the organization. It's parts are the people working there. The actual code is the job description. The programming language is how we write down the job description.

If we have structured text and ladder logic at our disposal best practice would be to use the language where we can describe the job in the clearest and shortest way possible.
Complexity is bad but if the job is complex the job description will by necessity be more complex too.

What we're trying to avoid is unneeded complexity because it takes longer to write, longer to debug, harder to change and longer to troubleshoot. It's simply a lot more expensive and inefficient.

A well rounded programmer should be fluent in both and pick the best option for each part of the program.

It's a fallacy to think that ladder become easier to troubleshoot just because it's ladder. Overly complex ladder can take a very long time to troubleshoot. And so does overly complex structured text.

But remember that HMI exists for a reason. Going to the program to troubleshoot is like pulling out the drawing for the transmission in your car when it doesn't start. Maybe you just forgot to put gas in it?

What you want is a good selection of alarms and be able to view the status of all sensors. You want to be able to test every piece of equipment from a HMI. For instance start and stop a motor manually. If your program has sequences you want to be able to view exactly where in the sequence it is and preferably what it is waiting for.

99% of all errors in a working program are not software related so going to the program to troubleshoot is not an efficient way of working and should be the absolutely last resort.

Designing the software with ample selection of troubleshooting for maintenance (without looking at the program) is IMHO the best way of doing it. Then using the software tools and languages where they fit best in the program.

Sorry for the long post guys! 🍻
 
Last edited:
... continuing with my reply marathon ...

LadderLogic:
========

You are correct. Sorry, "Phrog30", but I was taught in college by a very detailed and meticulous Pascal Professor NOT to use GOTO's, and I heard the same thing on my first professional job when a senior engineer, who's carefulness and attention to detail I can still remember, told me the same thing. It *may* have something to do with the potential loss of the GOTO label (which would generate a compile error), I'm not sure. It may also be because it's just not necessary to use, or that it's just considered "unstructured", which is a kind term implying "disorganized". But it *does* work.

Jmp/Label is the same thing as GOTO. In both cases, you are marking an instruction in your code and telling the compiler to generate a JUMP instruction back to the label. Why not use a REPEAT/UNTIL, or a DO/WHILE, or just a FOR loop? This way, the compiler generates the jumps and labels. Less error-prone, I'm thinking.

MitsM83:
=====

As I stated above, no Maintenance or Process people touch any Automation code here, but even if they did, I wouldn't code *for them*. They'd have to learn ST if they weren't familiar with it.

Peter Natchtwey:
==========
The IF-THEN-ELSE would be needed wherever an XIC or XIO or GT, LT, etc is used in Ladder. After all, "XIC" means "Examine IF Closed", right? But you'd have to include the ELSE each time because Ladder not only energizes if TRUE but de-energizes if FALSE. I think the compound IFs (where you string together ANDs across a rung and then tack on all the OR rungs off it) would be much easier to read in Structured Text because it would be more compact and would read like a book.

And colorization IS a nice feature, I'll admit that, but I don't see why ST couldn't do the same thing. If it's a boolean variable and it's ON, then show the variable name in bright green.

proof:
====

The PLC re-runs its logic continuously because the Operating System only provides a periodic task - which is only about 1/5 of what a full-blown OS would provide. But it turns out, that's all you really need because you are constantly checking all these switches to see if any of them have changed state, or you are constantly checking some varying analog input to see if you need to open or close a valve to control temperature or pressure. It's a potentially large number of independent I/O constantly changing that kind of determines how a PLC runs. From a real-time system execution standpoint, it's relatively simple, but it works well enough for the kind of data it needs to process.

mk42:
====

That's not correct. The PLC "starts over" because the Operating System is dispatching it for another execution. I THINK each task of your program is considered a separate task to the Operating System of a PLC because I THINK you can assign different execution times, correct??

The "C" programmer doesn't have to "manually start his program over again". It depends where that code is executing, and which Operating System it is running under. If it's just a DOS program, which is NOT real-time deterministic, then yeah - it just runs once and you'd have to make it loop infinitely to continue executing (and then you'd lock the machine up). But with any modern real-time OS, your code executes as a task under the OS and is given a time-slice to run, so it executes forever after you 'kick it off'. And if you make a coding mistake and create an infinite loop, the OS will terminate your task with the rest of tasks continuing to run (at least in theory).

daba:
===

Good point about use of JMPs and LABELS. It's just not considered good programming practice. Leave that stuff to the compiler writer.

As to your reply regarding the "popularity" of Ladder logic, I really believe Ladder has survived because Industrial Controls programming (for whatever reason) has lived in a vaccum all these years, while conventional programming languages have continued to evolve. Windows OS is not written in Ladder logic. No application that runs on your phone is written in Ladder Logic. Ladder Logic is not "popular", it's just a niche "language" that evolved for PLC processors out of the early days of relays. But instead of moving mainstream with the PLC programming language, Rockwell chose to expand Ladder to include Function Blocks, then user-defined Function Blocks, and that's about it. And while Ladder was probably readable in the early days, it's gotten too convoluted with all the rungs extending down the screen, and all the awkward wiring connections you have to insert when IFs start getting more complicated.

Mara:
===

AHA! So you *CAN* see 'active' variables in Structured Text (similar to the green colorization in Rockwell 'online'). Very good! And I agree that Ladder is less clear.

keshik:
====
Rockwell has a "bad ST editor"?? What's so bad about it? Are you saying it doesn't continuously check for errors (like Visual Studio and any decent editor nowadays does)?

JesperMP:
======
Like I said above, I agree that the green coloring in Ladder is useful, but that can also be done in structured text.
Not sure I follow your discussion about Ladder being a more "visual" language that requires no interpretation.

ndzied1:

Agree. Figure I'll end up with some mixing and matching of Ladder and Structured Text (and maybe even some Function Block).

As for the 700, 800, 1000 rung programs, those were written by vendors for large applications. They're broken down into multiple routines or tasks. Nothing bad about them, except that they're HUGE.

Cardosocea:
=======

I suspect you are saying it's a pain to debug a long sequence of ANDs and ORs in ST because you're assuming you'll lose the colorization you're accustomed to with Ladder. If the same colorization is present in Structured Text (and maybe Rockwell doesn't provide it, I don't know), then you can't tell me ST would be easier to look at than all those darn Ladder blocks strung together with all those wires, serpentining off the screen. No way.

dmargineau:
========
Linux would no doubt upgrade the capability of the PLC OS and make it look more like a conventional computer. It would probably also provide more threading capability to task modules.

AustralIan:
=======
Thanks for those visual suggestions. I'll think of that the next time I open an existing Ladder program. Really can't stand looking at one, to be honest. The serpentine rungs really irk me.

Phrog30:
=====

I think each programmer has to use what they are comfortable with. Rockwell provides Structured Text now so it's there to be used. Everything evolves and people have to adapt.

Pete S:
====

Couldn't agree more about visualizing the internals of your program through Maintenance screens and manual controls. Unfortunately, it hasn't happened where I am because people LIKE mystery. It keeps them employed. Seriously. It's wrong-headed thinking, but nobody's mandating any change in philosophy. It's OK to spend HOURS debugging even your OWN code (because even YOU can't follow it), rather than provide displays to allow Maintenance or Operations people to debug on their own.

But you're right - ideally, you rarely (if ever) have to look in the logic for anything. Then it doesn't matter WHAT language you wrote the logic in....


=============

Thanks for all the input. Very interesting stuff, I must say ...
 
Peter Natchtwey:
==========
The IF-THEN-ELSE would be needed wherever an XIC or XIO or GT, LT, etc is used in Ladder. After all, "XIC" means "Examine IF Closed", right? But you'd have to include the ELSE each time because Ladder not only energizes if TRUE but de-energizes if FALSE.

You are right about the ladder checking for both TRUE and FALSE logic solutions but you can (and probably should) convert to ST without the IF/ELSE structure if you can.

For instance:

START STOP RUN
-----] [--+--]/[-----( )
RUN |
-----] [--+



Can be written in ST as

Code:
RUN := NOT(STOP) AND (START OR RUN);
 
Cardosocea:
=======

I suspect you are saying it's a pain to debug a long sequence of ANDs and ORs in ST because you're assuming you'll lose the colorization you're accustomed to with Ladder. If the same colorization is present in Structured Text (and maybe Rockwell doesn't provide it, I don't know), then you can't tell me ST would be easier to look at than all those darn Ladder blocks strung together with all those wires, serpentining off the screen. No way.

Ladder is the language I program or deal with the less.
I was mainly referring to STL in Siemens (my bad) where logic could come up like this:

A M1.0
A M1.1
O (
A m3.0
AN m3.5
O m4.5
)
A I0.0
= Q0.0

Figuring out why the output isn't on with a chain like that or usually bigger is not easy.
The same can be said for Structured Text if the programmer puts in lots of conditions, I suppose.

About the visualization of ladder... I guess it depends on each person's experience. Although I don't write stuff in ladder, I am an electrical engineer and that is at times clearer than a text based language for boolean conditions. Anything else is a nightmare really.

You are correct. Sorry, "Phrog30", but I was taught in college by a very detailed and meticulous Pascal Professor NOT to use GOTO's, and I heard the same thing on my first professional job when a senior engineer, who's carefulness and attention to detail I can still remember, told me the same thing. It *may* have something to do with the potential loss of the GOTO label (which would generate a compile error), I'm not sure. It may also be because it's just not necessary to use, or that it's just considered "unstructured", which is a kind term implying "disorganized". But it *does* work.

I learned C and the same was told by my teachers that GOTO was not to be used without explaining why. This is either ignorance or lazyness from their part as the language is reviewed and adapted to be improved. If the GOTO instrution is so dangerous, why is it still present?
The reason, I find, is that goto promotes very ugly code that can easily get out of hand (spagheti code) especially for someone learning as it is the easy way out of some problems.
The link I posted previously has an explanation of why goto should be used.

Any if-statement is a goto. As are all structured loops. Ans sometimes structure is good. When it's good, you should use it. And sometimes structure is _bad_, and gets into the way, and using a "goto" is just much clearer. For example, it is quite common to have conditionals THAT DO NOT NEST. In which case you have two possibilities - use goto, and be happy, since it doesn't enforce nesting This makes the code _more_ readable, since the code just does what the algorithm says it should do. - duplicate the code, and rewrite it in a nesting form so that you can use the structured jumps. This often makes the code much LESS readable, harder to maintain, and bigger. The Pascal language is a prime example of the latter problem. Because it doesn't have a "break" statement, loops in (traditional) Pascal end up often looking like total ****, because you have to add totally arbitrary logic to say "I'm done now".
 
JesperMP:
======
Like I said above, I agree that the green coloring in Ladder is useful, but that can also be done in structured text.
You didnt read what I wrote. It is not merely the status of the variables. It is also the status of the logic result, even in the middle of a ladder rung. This helps enormously when troubleshooting.

I have attached a screenshot of what I mean.
You can see that in Ladder you can immediately know where the rung goes false. In ST you have to read and understand a code line and combine it with the logic status of the variables to know what is happening.
If any ST editor can do display the logic result in the middle of a code line I would certainly like to see it.
If the variables changes status more or less rapidly (which they will in almost any running PLC program), the advantage of the ladder view is even more pronounced.

Not sure I follow your discussion about Ladder being a more "visual" language that requires no interpretation.
ST is not visual or graphical at all. It is a text-based programming language. Sure, indentation helps, but you have to read each word to interpret and understand the meaning.
If you cannot see that Ladder is a graphical programming language, then I give up. It is impossible to explain.

N.B. My programming style is a mix of Ladder (~60%) and ST (~40%).

LadderLogicResult.png
 

Similar Topics

Is it possible to export a routine programmed in structured text and import it into a ladder routine?
Replies
2
Views
2,880
I created a new program task under that I created 2 ladder files. My first ladder does not have the 1 flag in the ladder icon designating it is...
Replies
8
Views
4,213
Hi all, Is there a equivalent function block that do the same as MOV function in ladder? Thanks.
Replies
5
Views
2,328
I am making some changes in a control logix PLC program that an engineering programmed for my company. In the program they have used the same I/O...
Replies
15
Views
7,412
Hi everybody, Until now I worked only with ladder logic. Now I have a program with function blocks. It looks more complicate, e.g. you have to...
Replies
4
Views
3,059
Back
Top Bottom