PLC Programming Language Decisions

When it comes to evaluating PLC programming languages, it’s important to realize you’ll likely use more than one. That’s why it’s key to pick the right programming tools for the job.

Though PLC (programmable logic controller) programming languages may not receive the attention that general computing programming languages, such as JavaScript, C#, or Python do, they remain critical to the manufacturing and processing industries. And while PLC programming languages have not been through as many changes or updates as general computing programming, these languages haven’t been static either.

To check in on the status of PLC programming languages, we spoke with Doug Yerger, principal engineer at Grantek, an industrial automation system integrator, for a recent episode of the Automation World Gets Your Questions Answered podcast series.

The demise of Instruction List?

One thing that hasn’t changed recently with PLC programming languages is that there are still two basic types: textual programming using typed out commands and graphical programming where logic sequences are arranged by moving objects around in the programming environment. Beginning our discussion with a focus on the textual languages, Yerger noted that the Instruction List textual PLC programming language is “a very low-level, mnemonic-based language” whose days look to be numbered.

Instruction List has been “deprecated in IEC 61131-3 and will probably not be in the next version of the standard, according to the standard itself,” he said. “I think you'll see controllers and programming software that support Instruction List now will continue to support it for quite a number of years, but I don't think you're going to see anyone put it into their [new] product lines if it's a deprecated standard.”

Structured Text example. Source: drivesandsystems.comStructured Text example. Source: drivesandsystems.comThis deprecation of Instruction List in the IEC standard is happening because the language is seen as an “outdated, assembler-like language,” Yerger said. “And talking with my peers in our company, no one's seen Instruction List utilized in any of our projects. We stick to Structured Text and the other languages.”

Despite the grim outlook for Instruction List, Structured Text will be sticking around as it’s a high-level programming language. “If you're coming from a computer science background, Structured Text is going to be very native field for you. It's also very good for looping and string manipulation,” said Yerger. “And if you have to parse barcodes, strip out the ASCII characters, and things like that, that's so much easier to do in a high-level textual language than in [a graphical programming language like] Ladder Diagram, where you're going to be dealing with each byte individually.” 

The graphical programming realm

Explaining the principal differences among the graphical PLC programming languages, Yerger started with Ladder Diagram, noting its development from relay logic. “It (Ladder Diagram) looks like old school hardware relay logic diagrams. It's basically all Boolean math and Boolean decisions, for the most part,” he said. Meanwhile, the Function Block language allows programmers to arrange different blocks on a graphical screen that represent the inputs and outputs between the controller and the devices connected to it.

Sequential Function Chart example. realpars.comSequential Function Chart example. realpars.comYerger describes the Sequential Function Chart language as being “the oddball of the five [PLC programming] languages. We don't view it as a language, it’s a structure of the flow of the logic, because it allows for branching into parallel processes that are decision points based on conditions. Basically, with Sequential Function Chart, there's an action item at each block and each action can have series of events. These events are going to be what happens in each of those action blocks. But the events will probably be programmed in Ladder Diagram from the Structured Text function blocks. Sequential Function Chart controls the flow [of operations] by saying, ‘do this and wait until this condition is met.’ It parses down the program flow this way by giving directions based on conditions being met. So that's where it's a little different than the other languages.”

Ladder Diagram example. Source: automationprimer.comLadder Diagram example. Source: automationprimer.comThis program flow nature of Sequential Function Chart is why it’s so often used. “It’s great for stepped or discrete sequencing. A classic example would be a batching engine where you might have, say, three ingredients added together for a recipe and those ingredients are going to be three parallel branches in the programming language. But you're not going to turn on the mixer’s agitator until all three of them are added. So you’ll have this series of steps that need to happen—some parallel, some sequential—where the controller is going to wait for the conditions between them to be met before moving forward. When you get to the agitation step, control of the motors might be done in Ladder Diagram, which will trigger the Sequential Function Charts running in a separate process. When the Sequential Function Chart program sees the trigger of the agitations completed, it's going to move on to the next action in the sequence.”

Doug Yerger, principal engineer at GrantekDoug Yerger, principal engineer at GrantekIn North America, more than 90% of control programming is done in Ladder Diagram, said Yerger. “It's great for discrete logic systems that use a lot of Boolean algebra and have a lot of limit switches and on/offs,” he said. “It's also very easy for experienced electricians to understand because they're coming from the hardware reading (that Ladder Diagram is based on). Newer technicians that have learned C or other high-level programming languages are probably going to lean toward Structured Text because it will be more familiar to them.”

Function Block programming is preferred for continuous processes where you're taking an analog input and scaling it, said Yerger. That’s why it’s often used for PID loops. There are also several safety systems that use Function Blocks as their programming method, he added.

The main takeaway when looking at the different PLC programming languages is that it’s rare for just one to be used. “Especially if it's a large program, we're going to have routines and programs in them that use a variety of languages,” Yerger said. “The majority might be in Ladder Diagram, but if we have a big array processing to do, we're going to use Structured Text to handle those arrays. We're not going to stick to just one [language] unless, of course, our customer has that requirement. And there are several customers that do say: Use Ladder only. But we usually try and talk them out of that and move them to a more modern philosophy of using the right tool for the job.”

Beyond IEC 61131-3

The introduction of programmable automation controllers (PACs) for more complex automation tasks expanded the realm of controller languages beyond the IEC 61131-3 languages, allowing for the use of languages more connected with the IT world, such as C and C+.

Yerger said there was a big push several years ago to bring the “C” programming languages to the plant floor. But he said that push slowly faded away in favor of the IEC languages. However, he did note that IT programming languages are still prevalent with SCADA systems. “If we need to do high level C, Python processing, or even Java processing, we're going to take it up to the SCADA level and do it on computer hardware that has the power designed specifically for those languages,” he said.

   Read about making the decision among PLCs, PACs, and IPCs.

Companies in this article
More in Control