Which IEC 61131-3 programming language is best? Part 1

Programming language choices for programmable logic controllers (PLCs) are many. It is said the great thing about standards is there are so many to choose from! While this is meant as sarcasm, in the case of IEC 61131-3 Programming Languages, it is an advantage to have several language standards from which to choose.

Many students enter my training classes with the mindset they will choose the language best for them and then specialize in that language. At the beginning of class, they often ask what language I recommend. Or, “What is the best language?”

I usually respond to this question by asking, “What is the best number in the Hindu-Arabic number system?” or “What is the best word in the English language?” (A student recently said the best English word is “spork,” but I think that answer is still awaiting universal consensus).

A good analogy is to ask which is the best office productivity software tool – a document editor, a presentation editor or a spreadsheet editor? While presentations and spreadsheets can be created with a document editor, is that the right way to go? Likewise, presentations and documents can be created in a spreadsheet tool, and documents and spreadsheets in a presentation tool. Does any of this make sense to do, though? Is it worth the effort to learn all the tricks required to make one tool serve multiple purposes, or is it more efficient to learn only the key features of the tool meant for the job?

A similar analogy can be made with lawn power tools. As countless YouTube videos have shown, it is possible to use a mower to trim hedges. (Please, don’t try that!) It is much more efficient (and less hazardous) to use the right tool for the job.

As with lawn power tools, it is most efficient to use the best programming language for the application, to avoid the complexity of driving the square application peg into the round tool hole. With IEC 61131-3 programming languages, PLC programming and maintenance are enhanced when the strengths of all the languages are used.

Programming languages: LD, SFC, FBD, CFC and ST

“Which IEC 61131-3 Programming Language is best? Part 1” (this article) discusses the strengths and best applications Ladder Diagram (LD) and Sequential Function Chart (SFC).

“Which IEC 61131-3 Programming Language is best? Part 2” will discuss Function Block Diagram (FBD), Continuous Function Chart (CFC), Structured Text (ST), and how they can be mixed and matched for optimal results.

What is Ladder diagram (LD) programming?

Ladder diagram programming, or LD, traces its history back some 100 years to relay ladder logic (RLL), which was created to describe systems of electrical components such as relays, timers and motors. In the early days of automation, when PLCs were replacing relays and timers, it made perfect sense to create a programming language familiar to the user base and similar to the tool it was replacing. Unfortunately, as controllers became more capable and evolved past relays and timers, the original LD language was pressed into services it was never intended for and was poorly suited.

This situation was exacerbated by the slow pace at which PLC vendors provided new languages better suited to PLC and programmable automation controllers (PAC) applications. This was particularly true with controllers originating in North America, which explains the global differences in the enduring popularity of LD.

Strengths of LD programming

The strength of LD and the key to its enduring popularity is its graphical nature. Of all the generalizations one can say about engineers (as is often illustrated in your favorite Dilbert cartoon), it is safe to say engineers tend to be graphically oriented. (Who among us can effectively communicate without paper and pencil, or a white board?) Early on, most LD programming alternatives were text-based languages that did not resonate with engineers’ graphical nature. This led to further reluctance to move on from LD. Fortunately, that situation is changing.

LD remains a great language for which it was originally intended – complex Boolean logic. Staying within this realm, LD logic is simple to design and simple to debug. Figure 3 illustrates this point by showing the same Boolean logic in several IEC 61131-3 languages. Say we are expecting “Inspect” to be TRUE. How easy is it to determine why the result is not as expected? In LD, the answer is quickly determined by observing where the path of solid blue contacts is interrupted (GantryIsRight is not TRUE). In CFC and FBD, the issue also can be determined by observing the progress of the blue path, but it does require mentally evaluating the ANDs and ORs. Evaluating the issue in text is a challenge.

What is sequential function chart (SFC) programming?

Sequential function chart (SFC) is a graphical language great for expressing state machines, and, like LD, appeals to the graphical nature of engineers. To provide better context, this programming language discussion will be broken into two parts:

1) State machines in general, and

2) The language to implement a state machine.

What are state machines?

State machines date back many years, but only more recently have been applied to industrial programming. State machines are a very powerful method for expressing a system whose behavior depends on past history, such as any logic with:

1) Set coils or reset coils

2) Seal-in logic (Boolean feedback)

3) Internal flags that are set by the code to affect the behavior of the code on future scans.

In reality, even the simple TON On-Timer and R-Trig one-shot are state machines. Their next behaviors depend on previous inputs and behaviors as shown in Figure 4. (Has IN gone true? Has the target time been reached?)

State machines offer many benefits over other coding techniques:

1) They’re easy to design because it clearly describes the states a system can be in, how the system transitions between those states and the actions the system should take while in those states.

2) During runtime, it is easy to see exactly what state a system is in, what it is doing in that state, and what will cause it to move to the next state (or why it isn’t moving to the next state if something has gone wrong in the process).

3) It promotes well-conceived and well-organized designs. It assures all possible eventualities have been handled (thus eliminating the chance of being called in the middle of the night to fix code that didn’t properly address an unusual condition).

4) Easy to determine that every possible eventuality has been properly tested. Just print out the SFC and cross off each state and transition as it is exercised. When everything is crossed off, testing is complete (and the programmer’s confidence level is 100%).

State machines can be implemented in different ways.

How to implement a state machine

While state machines can be implemented in almost any language, they require a specific coding technique, which consists of steps, transitions, branches/jumps, and actions.

Steps describe the states of which a system can reside; Transitions indicate when a system should move from one step to the next; branches and jumps indicate what that next step should be; and actions specify what operation should be performed while in that step (or entering or exiting that step).

Due to its graphical nature and specialization for the job, SFC is the most natural choice of language for state machines as shown in Figure 5.

Figure 6 shows an example of a state machine for a loading system as displayed in the online mode where the current states are displayed in blue. Notice this example has three simultaneous parallel branches that run independently of each other. Also notice how simple it is to determine the current state of the system, what the system is doing in the current state, what the next states are, and what conditions are required to move on to the next states.

For system requiring unusual complexity or flexibility, state machines also can be implemented in text-based languages as shown in Figure 7. For organizations locked into using LD, state machines can even be implemented in LD by using a coil for each state, transition logic to energize/deenergize each coil to move the system from one state to the next, and separate logic that uses state-coils to implement the actions.

Some vendors also provide an implementation of unified modeling language (UML) state diagrams as a more powerful and flexible alternative to SFC, but this comes at the price of a longer learning curve and limited acceptance in the industrial controls community.

When it comes to state machines, the choice of language is secondary to the choice of technique within the language. In SFC, the language forces the use of the state machine technique. In other languages, it’s up to the discipline of the engineer to use the proper technique. If the functionality depends on previous history, it’s a state machine. For optimal code, implement it as such.

[A related Control Engineering article explains “UML use cases, sequence diagrams: easily converted into executable code.”]

Use the right language for control system programming

To communicate effectively in the English language, it’s important to have the right vocabulary and know how to use that vocabulary effectively. To create effective industrial controls programs, it is important to have the right languages and know how to use those languages effectively. IEC 61131-3 provides the languages, and this article has provided guidance on effective use of LD and SFC. See Part 2 for use of FBD, CFC and ST. Go forth and program effectively with IEC 61131-3 Programming Languages.

Gary L. Pratt, P.E. is president of ControlSphere Engineering. Edited by Mark T. Hoske, content manager, Control Engineering, CFE Media, mhoske @cfemedia.com.

KEYWORDS: IEC 61131-3 Programming Languages, LD, SFC

CONSIDER THIS 

What IEC 61131-3 programming language best fits your task?

This article was published in "Control Engineering"July 2020.

ONLINE

For more, see:

Video demonstration of each language and configuration from a csv file.

Object Oriented Industrial Programming (OOIP) article.

More programming downloads from Object Oriented Industrial Programming Foundation.

www.ooip-foundation.org

CODESYS integrated development environment (IDE) from the CODESYS Group, used for examples in this article can be downloaded at no charge, including a software-based PLC that will run for 2 hours between resets.

For a Control Engineering article with programmable logic controller programming instructions, terms, logic circuits and more, see “Support-focused enterprise controls: PLC Basics.”

Online extra 

Author biography: Who is Gary Pratt? 

Gary L. Pratt, P.E. is president of ControlSphere Engineering. Pratt’s career began with Chevron Corporate Engineering in 1982 and has included numerous positions throughout the industrial controls industry. He holds patents in industrial controls and now concentrates on sharing his knowledge and experience with the next generation through IEC 61131-3 Programming Languages and CODESYS integrated development environment (IDE) consulting and training classes. 

Related Articles

• Leverage object-oriented industrial programming
• Leveraging OOIP, Part 2: Abstraction, nesting and interfaces
• OOIP Part 3: interfaces and methods