Blog

Ladder logic, the primary programmable logic controller (PLC) programming language, is simple and represented graphically as relay contacts and coils. The question is, though: How well can ladder logic serve the complex automation needs of the present and future compared to other programming languages? The answer is more complicated than just contacts and coils.

Ladder logic origins

Automation existed before PLCs, frequently using a network of relays for the brain of an application. There wasn’t a programming role; there was an engineer to design the circuit and an electrician to assemble it. The circuit would be documented in a standard structure that resembled a ladder when drawn on paper, hence the name “ladder diagram” (see Figure 1).

When PLCs arrived, they promised a lot of benefits to automation, but nobody knew how to program them. Then someone got the idea to program the PLCs with the ladder diagram, which allowed the industry to repurpose existing skill sets for programming. Engineers and electricians could read and understand the programming, and automation design could largely follow the same patterns it had with relays.

Before PLCs, relays took up physical space in a cabinet, cost money to buy, and required time to wire.They were also limited to on/off functionality-without capabilities for analog, math, or data collection in relay logic (aside from some sparse timing and counting functions in special relays). Even the largest, most complex automation systems were limited by the realities of physical relays, so the language of ladder logic didn’t have to do very much.

Today, the processor chip inside a PLC can do more than relays at a much lower cost of space, money, and implementation time. In turn, the programming languages used in PLCs have grown to reflect the increased capabilities. Ladder logic does a lot more today than it used to. PLCs commonly are used for analog control, tracking part data (barcodes, test results, calibration), controlling motion, and a plethora of other tasks-and ladder logic is still the dominant language. As the language has evolved and automation has become more complex, programming PLCs has become a more specialized occupation. Ladder logic is no longer such a convenient language for electricians to read and maintain, nor is it a broadly existing skill in the incoming workforce.

Other PLC programming languages

Industrial programming is influenced by two communities: the standard IEC 61131-3, the industrial control programming standard from the International Electrotechnical Commission; and PC programming. These languages usually are seen as complementary to ladder logic, rather than directly opposed.

IEC 61131-3

As PLCs became popular, the industrial community found the need for standards to guide programming. The IEC’s committee addressed this need with standard IEC 61131, and languages specifically in part three (61131-3). This defined four programming languages that generally were interchangeable-ladder diagram, function block diagram, structured text, and instruction list-and also a program organization language called sequential function charts.

Each language has its own strengths and weaknesses, and they can be used together within one program to best support different program functions. There’s certainly room for debate on which language is best suited to which task (see Figure 2). Generally, a process will operate as discrete or continuous. Automation also tends to lean towards mostly digital input/output (I/O) or analog I/O.

PC languages

The languages drawn into automation from the PC world tend to be used for specialty/peripheral applications. That may include interfacing with databases or programming automation peripherals like cameras and robots. Structured text (defined in IEC 61131) is a very similar to Pascal, a common PC programming language at the time IEC 61131 was introduced. Pascal has since fallen out of favor, but it’s a great example of how the automation industry has borrowed from the PC industry in the past. Current examples of PC languages in automation include C++, Java, and C#. These languages are powerful, but haven’t found a strong foothold in automation.

Three programming questions

Before comparing ladder logic to other potential options, it’s important to understand what a program really needs to do. A program has to make the automation work, which virtually any language can do, but the real world puts other demands on it as well. This largely boils down to readability. Ask these three critical questions about your programming languages.

A. Can a programmer or maintenance technician look at the code and understand what it does?

B. Can problems be found quickly to minimize machine downtime?

C. When new functionality is desired, how easy is it to extend the program?

There are features of different languages that affect a programmer’s ability to make a readable program. Nine areas in particular can influence programming language selection.

1. General knowledge

Ladder logic is widely used, which makes it easy to find someone who can read it. Other IEC 61131 languages show some preference within certain industries, but aren’t as universally used or understood. The PC languages used in automation tend to be very popular and have a lot of support resources, but not always in the industrial community, which diminishes potential benefits.

2. Internal documentation

Every language has a way for the programmer to explain the intent of the program in plain English. In ladder logic this mostly is done with rung comments and tag (variable) comments, which work well for simple rungs, but can be less helpful for larger rungs or math.

Other IEC 61131 languages vary, but are generally good for documenting the things they’re good at. For example, structured text allows good documentation of math and loop structures.

PC languages tend to have a lot more functionality available with many options for internal documentation, and sometimes even auto-generate documentation from the source code, creating a manual for a programmer or technician to reference and understand the big picture quickly.

3. Decision structures and loops

At a simple level, programming comes down to “if this happens, do that.” This is a decision structure called “if-then,” and it’s easy to use and understand in all languages discussed here. But what if the programmer wants to do something more than once? These structures aren’t well supported by ladder logic, usually resulting in code with poor readability. Structured text and PC languages, on the other hand, tend to be very good at all common decision and loop structures.

4. Math

Addition and subtraction are easy, and work fine in any language, but what happens when complicated math is involved? Ladder logic supports arithmetic and some basic functions like absolute value or square root, but as calculations involve more pieces, they tend to be less readable. Comments get separated visually from the things they’re documenting, and doing the same math operation more than once isn’t pretty since loops aren’t pretty. Structured text and PC languages tend to be more graceful with large math functions. PC languages also offer high-level math functions for virtually any purpose and are packaged for easy use.

5. Visibility

Reading an unfamiliar program is like reading a choose-your-own-adventure novel through a paper towel tube. You have to page back and forth between different parts of the book and you can only see a little bit of the page at a time. The amount of code that fits on the screen can impact a programmer’s ability to figure out what the program does and how. Ladder logic typically displays one to five rungs on the screen at a time. Its graphical nature makes it information sparse, and it’s harder for a programmer to “see” the whole program. Sequential function chart, also graphical, avoids this issue by being high-level and limited in nature, like a short book with a table of contents. Text-based languages (structured text and PC languages) tend to be more dense, showing 30-50 lines of code on the screen at one time.

6. Encapsulation, code reuse

What’s the answer to increasing complexity? Abstraction. When driving a car, the driver isn’t thinking about the ignition timing, the traction control, or the engine cooling strategy. All of the other stuff is abstracted away, self-contained, and self-managing. In programming, this is called “encapsulation,” and it’s got a benefit beyond just making things easier to understand in varying levels of detail; it also means the code can be reused. If a machine is programmed to calculate overall equipent effectiveness (OEE) for every hour in the day, it can be coded to calculate OEE once, then reuse it for each hour. Ladder logic and other IEC 61131 languages do this well. PC languages add object-oriented features, which make this much more powerful. IEC 61131 has provisions for object-orientation, but they’re not always implemented by PLC manufacturers, which means programmers can’t use them.

7. Libraries

Libraries let users take code reuse to the next level by adding someone else’s code to a program in encapsulated, tested pieces. Like the car example, users don’t even have to know what’s under the hood to take advantage of it. Ladder and IEC languages have limited support for this type of functionality.

PC languages have a lot of library support, often for free. These aren’t intended to cover the functions ladder excels at, but often apply in areas where ladder is less applicable such as math, vision inspection, and data handling.

8. Analog vs. digital

In many ways, the analog vs. digital argument is similar to the math argument. Ladder logic does very well with digital signals and information, but is less graceful with analog. Function block, another IEC 61131 language, does very well with analog signals, but is less elegant with digital. Structured text and PC languages tend to handle both well, but since they’re more flexible, there’s more need for the programmer to organize the code well for readability.

9. Determinism

In automation, it’s usually important for the controller (PLC, PC) to read inputs, run the program, and write outputs in a repeatable time frame (for example, every 15 ms). This is called determinism. Ladder logic and all IEC 61131 languages are deterministic. PC languages vary. For example, C++ can be deterministic, but higher-level languages like Java and C# generally can’t provide determinism.

What’s the best option?

So how does ladder logic match up against the rest? It remains favored by the discrete automation industry where digital inputs and outputs are the norm. On the other hand, the process industry, where analog inputs and outputs are dominant, makes good use of the function block language to handle those portions of code.

Of course, industry preference is dominated by only one of the above considerations: support.

Available support is largely an expression of historical norms because recent history dictates what experience the workforce has today. Since ladder logic has been the norm for so long, using a different language may seem like a scary prospect.

However, new grads have experience with text-based languages and not with ladder logic. As the workforce turns over, the industry preference will likely skew toward text-based languages as more support becomes available. In the end, though, automation is likely to have multiple languages involved in its operation. Thinking in only one language can be detrimental to those goals.

The PLC will use one or more language, and so will many of the peripherals. It’s important for a programmer to know what languages are available, what they’re good for, and how to apply them with the intention of creating readable, supportable code.