Introduction

Ladder programming has been the de facto standard for PLC and Machine controller programming for decades. It evolved from a circuit diagram, where the left hand vertical rail was positive and the right hand rail was negative. Traditionally relay logic was drawn between the two vertical rails. We still consider the program execution in Ladder from left to right, just like the power flow of a physical circuit (well "conventional flow", not electron flow!). 

Ladder Diagrams are great for Fault finding

Ladder programming is very popular, because the IDE such as CX Programmer or Sysmac Studio draws the "power flow", an activated line from left to right and this conveys a lot of information. It can easily be seen why an output is not on, the "power flow" is interrupted for instance by a contact or a comparison that is not true. This visual feedback of the state of the program allows electricians to quickly visualize and interpret the state of the system. It is almost second nature because it emulates circuits very well. 

However, as Machines, Programs, Functions and Function Blocks become more complex, we are hiding more complicated code inside of modules: programs are more modular, and Function Blocks wrap a lot of code into a single entity that the maintenance person only needs to be concerned with the outside of. The inside should be very well tested and robust and what we put inside a Function Block or Function can be either Ladder, or Structured Text. No matter what is on the inside, we can call the function or Function Block from Ladder or Structured text based programs. 

I would have loved to have today's controllers 30 years ago when the applications were challenging for that days technology. Today's controllers, with the modern programming concepts would have solved the control requirements so easily, we would hardly be challenged. But as capabilities have advanced, so have the applications, and no matter how capable the controller becomes, applications constantly challenge what is possible. The edges of capability are on speed, complexity and data handling.

As Machine Controllers become more advanced, there is more technology merging from the IT space into the machine. OMRON machine controllers can directly interface with SQL databases and read and write data at high speeds. This was the realm of the PC as a middle man for a PLC, now this capability is built into the controller. They are also motion controllers, handling high speed trajectory calculations, they can control robots and execute the kinematics in real time, while also controlling the whole machine with dozens of high speed synchronous and independent axis control at the same time. 

All the above is challenging which is the best language to use in Automation today. I grew up with Ladder, loved Ladder and hated Structured Text when I first started. Now I love Structured Text and do not enjoy programming in ladder anymore. I only write program samples for others in Ladder, any serious program, including the inside of any Function or Function Block I write is Structured Text. 

Making the case for Structured Text

Firstly what is challenging about Structured Text is interpreting it when it doesn't work as first expected, finding bugs is more challenging. It is a more intellectually challenging activity than looking at power flow on a Ladder diagram. But having said that, working with Structured Text requires a more disciplined approach. Untidy code stands out in Structured Text. Conversely, well structured code in Structured Text looks elegant and "correct". When you get the hang of Structured Text, you are probably going to prefer it. This is a very subjective statement however.

Performing math in ladder is generally quite messy. An operation is performed and the result is output, stored and reused in the next ladder instruction as an input. What can be done in a single line of Structured Text takes many, even dozens of lines of ladder to accomplish. As the code is more compact, you can see more of your machine control code on a single screen. We also work more with strings, and assemble complex operations for interfacing with web devices. Ladder is cumbersome for this, Structured Text has a clear advantage for any complex programming. 

Digital control is easy with Ladder, complex programming is easier with Structured Text. Maintenance staff will almost universally demand Ladder. But this will change with time.

Structured Text is also more portable between controllers from different vendors, it is as simple as copy and paste being text based. Trying to copy Ladder code from one controller brand to another will never work. Structured Text is very handy for this.

Check your controllers capability

In OMRON C series PLCs (eg CJ, CS, CP etc) the Structured Text implementation is not full IEC61131, they were developed prior to this standard and based in the days of proprietary instruction sets. Ladder contains the full programming instruction set while Structured Text does not. In these controllers, I would recommend always sticking with Ladder programming, otherwise you will not have the full instruction set at your fingertips.

However, Sysmac Studio is a completely different story being designed in an era of IEC61131-3 (a standard relating to Industrial Controllers), every Function and Function Block is available for use in Ladder or Structured Text. Sysmac Studio even allows the programmer to combine the best of both worlds: Ladder programs with blocks of Structured Text. Typically a programmer can get away with math or setting variable values in a Structured Tect block, even when maintenance staff demand Ladder code. There are circumstances where Structured Text is more readable and actually easier to understand than Ladder. So Structured Text is creeping into programs, even when by rights, the Maintenance Staff would object to it.

State Model Programming

One of the concepts that all programmers should be using is State Model. State Model defines that the machine should be in one or more states that are clearly defined. For instance, the machine should be in Manual Mode or Auto Mode. It should be Idle or Starting, Running or Stopping while in Auto Mode. There are many different modes it could be in, but they should be very well defined and clear transitions from one state to another. 

State Model programming would not allow a machine to be in Manual Mode and Auto Mode, this is confusing. While both Ladder and Structured Text can be used for State Model programming, Structured Text is easier to program. The CASE statement is a wonderful construct that allows simple implementation of state models. Ladder can be made to work, but it is not as elegant. PC programming concepts such as derivative data types (structures, enumerators etc) are easier to use and more readable in Structured Text.

Which should I choose?

This is very hard to answer. It depends on who will support your program as well as what is the best for the application. It also depends on your experience. These days more PC programming experienced programmers are entering the Automation space, and bringing their preferences with them. At OMRON we generally program in Structured Text inside of blocks, and allow our customers to implement in either language to suit their needs best. Try both and see what is a better fit for your application, and your teams. 

However I am sure that one day Ladder will die a quiet death, and Structured Text will be there to lay flowers on it's grave. Its only a matter of time.