Technical Article

Alternative PLC Programming Languages

August 27, 2020 by David Peterson

For most systems, there are various languages meant for specific purposes, including Function Block, Sequential Charts, and Structured Text.

By far, the most common programming language for PLCs consists of rungs of if-then logic, similar to an electrical line diagram, going by the name of ‘Ladder Logic.’ Many programmers have quite likely been exposed only to this language exclusively.

There is a small variety of different program options besides the standard ladder logic for some programmable controllers. Most industries primarily use ladder logic, so most programmers have never selected any other option, nor explored the use and purpose of these alternatives. Just as ladder logic was designed to meet a specific need, so were the others.

First, the background of ladder logic may provide some context for the popularity of this programming method. PLCs were initially designed to replace relay logic controls. These relays used coils and contact sets to perform massive sequences of instructions. The PLC replaced the relays with a much smaller, more efficient form factor. The electricians working on the relays had to shift skills to working on these computers instead.


An industrial PLC used in a facility. 

Programming languages like BASIC and others that resemble modern Java or C++, for example, were not readily accepted by electricians. Without proper training, it would take hours to track down even simple sequences to troubleshoot failures.

The development of ladder logic was the idea of representing the computer instructions as pictures that looked like electrical symbols, making it more readily accepted and understood by the industrial users. It would probably be accurate to say that ladder logic programming played just as important a role in the rise of PLCs as did the actual control hardware itself.

It’s no surprise that the most common entry-level training programs focus on ladder logic, and therefore the learner tends to stick with what they know. However, there may be some good reasons to choose something other than ladder logic for some projects with some exposure to the alternatives.


Function Block Diagrams (FBD)

This type of programming is quite familiar to most PLC programmers, although they might not realize it. 

Function blocks consist of operations with one or more inputs, discrete contacts, or variable values. Inside a block, some procedure takes place, resulting in output value. This value is then sent to another block as necessary.

A block is usually a square with inputs on the left side and output on the right. As an example of what this may look like, many typical math and inequality instructions and timers and counters are usually functional blocks inserted into ladder rungs.

The unique part about FBD programming is that there are no ladder rungs, and the function blocks are connected in free space. For most PLC programmers, the shift from ladder (LAD) to FBD programming isn’t too difficult.


A sample of the ladder diagram commonly used. 


The FBD language would be primarily used when most of the data is analog or integer values for which the simple coil-contact setup of ladder diagrams would not work well. In those cases, the ladder diagrams already consist almost entirely of function blocks, and FBD programming may simplify the programming with better capabilities.


Sequential Function Charts (SFC)

This language could be simplified with the word ‘flowchart’. It is quite different from ladder logic in which each rung is an entirely separate operation. Sometimes, one rung may influence another rung, but each rung is still examined and calculated as a unique tiny program.

In complete contrast, Sequential Charts cause conditions and values to have a single starting action or operation, which leads to subsequent steps as long as conditions are met. This programming language can still perform all the necessary calculations and networks with external equipment (sensors, motor drives, etc) but everything is represented as a sequence of steps.

Ladder logic is preferred for continuous processes such as assembly lines or distribution centers where inputs are continuously examined, and outputs are continually activated. However, SFC is ideal for batch-type functions that have a very defined starting point, and an easily measurable progression of steps leading to a conclusion. Quite often, these processes will be drawn up as a flowchart on a whiteboard, and this makes a perfect candidate for an SFC program.


Structured Text

In all of these previous graphical languages, instructions are chosen from a pre-set list of options. The user will click and drag the instruction into the workspace. Sometimes there are add-on instructions. But there are some processes in which the software may not provide the instructions that are required to get the mission accomplished.

Structured text is a much more high-level language that can actually directly read any input, write to any output, and provide access to every part inside the controller, including communication ports. If a custom packet must be sent over a twisted-pair wire, there may not be an instruction that will work.


Example for a network in the sequential function chart. Image courtesy of Beckhoff Automation

Structured Text may be very powerful but is also the least intuitive for most technicians. It might require the skills of someone with a programming background, but it does allow the PLC to be configured for nearly any task - even if the software does not include that one required instruction for a task.

These languages, graphical or text, must be converted into assembly-type instructions to send to the CPU. These instructions are part of a fifth ‘language,’ which is called “Instruction List”. A knowledgeable programmer could directly program these instructions, which closely resemble the G-M Codes used in a CNC controller. 

The variety of languages that exist for PLCs may seem overly complicated, but each one is meant to solve unique challenges. It may be well worth the exploration of different programming strategies to tackle these different scenarios.