IEC 61131-3 programming: Where’s structured text more appropriate than ladder logic?

No one IEC 61131-3 language leads for all uses. In fact, the best way to program with IEC 61131-3 languages is by using multiple languages together. That accommodates (among other things) the way every engineer has a different methodology for programming.

Sequential function chart (SFC): Recall that SFC is the highest-level code standard in IEC 61131. It is not technically a language but rather a means of partitioning code and visual display of the machine state or the mode in which a machine is currently running. States can be initialization states … or going from an initialization state to a standby state … or shifting from that state to an automatic or even manual mode … and so on.

SFC basically consists of diagrams showing how a machine should operate — serving as an operator layer that lets anyone approach and investigate sequential function charts and immediately understand how the machine is supposed to run — as well as processes associated with a part or material entering the machine … and what the end result will be and look like. Having these separate modes means engineers and operators can easily go into each and drill down to a “maintenance” layer.

Ladder logic: Many engineers fear that IEC 61131-3 aims to abolish ladder logic — though that’s simply not true. Many U.S. maintenance personnel have a long history with it. It’s a familiar and visual language that clearly displays sets of inputs, response actions in particular modes, and expected output. That’s a perfect maintenance layer because it clearly shows causal relationships — to let personnel troubleshoot and write code for the right aspect of the machine within that node causing problems.

The problem is that ladder limits other kinds of machine programming. Traditional designers program ladder logic in software such as C# and C++ as well as Python — visual languages that vastly complicate (or are incapable of) advanced mathematics, data processing, and cross-component communication drivers. For such operations, it would take a programmer an inordinate amount of time to click and drag and create coils. Resulting programming would also be quite unwieldy — with rungs and rungs of visual code incredibly difficult to debug.

A better choice for more involved processes is function blocks. The code lets programmers set an action and output action wrapped in a function block — because maintenance personnel don’t necessarily need to see developer back-end code. Programmers can put their structured text in that function block and that in turn can be locked down to into a library. Such code can be compiled and even protected as part of the OEM’s intellectual property — IP in back-end structured text that end users can’t access.

Such layering of code with IEC 61131-3 and forethought about all the ways in which different personnel will interact with the design makes machine builds more robust. Asking who will ultimately read the code (and which language would be most helpful for them to interpret what the program is trying to do) also makes the design more accessible. Frameworks such as Packaging Machine Language (PackML) and guidelines abound to make such layered code easier to write.

So are certain languages more common for motion control?

As mentioned, one key strength of programming with IEC 61131-3 is that it allows layering of code in multiple languages. That addresses the varied needs of all personnel types who will ultimately need to operate and access the machine and its code. It also lets engineers get away from using one language for everything. After all, some languages work better for process-oriented tasks than discrete motion control, for example. The IEC 61131-3 environment lets engineers blend even such disparate programming together. There’s accommodation of PLCopen motion-control function blocks (with PLCopen being another industry standard to level the playing field for motion-control manufacturers) with motion functions such as MC_Power to power drives and MC_Jog to move motors, for example.

• One common approach is to create motion-control code in structured text (ST). Staunch adherents to structured text feel ST excels in nearly every situation. However, a drawback can be less accessibility for technicians.

• Another common approach is to create motion-control function blocks at the ladder level — especially where maintenance personnel may need to understand and track machine functions) or sequential function charts for higher level perspectives on whole processes.

Aren’t function-block diagrams mostly for process control — not motion control?

Today’s programmable automation controllers (PACs) and the ways motion control has evolved over the last five years means there’s now more fluidity in what languages are used where. Controller hardware in the form of PACs is a vast departure from legacy systems with different devices performing different jobs — with a standalone motion controller segregated from the machine’s PLC set aside from its HMI. So it used to be that all this hardware was associated with different processes and software. Now unifying hardware along with IEC 61131-3 has substantially changed the way industrial coders program — and even the ways industry conceptualizes discrete versus process control … as now they’re often run off one device with a flexibly selected mix of languages.



Insight from this FAQ derives from a recent chat with Marissa Tucker, product manager of controls and automation at Parker Hannifin about specifying controls based on standards rather than brands. For more information from Parker on PACs as well as free simulation software for trying out IEC 61131-3, visit parker.com/emn/pac.