Understanding the IEC 61131-3 standard
PLCs generally are not cross-compatible. Most PLC programming environments are vendor-specific, meaning that a program written for one device, and even from the same manufacturer, will not compile and run on a device produced by another manufacturer. This means that without standardization, this could lead to utter chaos in the field. Each PLC could easily have not only its unique programming environment but also its own set of rules that govern that environment. A developer migrating from one PLC brand to another may have to take extra time to learn the new programming system. However, the purpose of the 61131-3 is to provide a standard so a developer can easily switch from a PLC of one brand to a PLC of another without having to learn a whole new programming system. In short, the IEC 61131-3 standard makes migrating from one compliant PLC to another as simple as writing the code in a new environment.
This is where the IEC 61131-3 standard comes into play. The IEC 61131-3 is a vendor-neutral and hardware-independent PLC programming standard. The goal of the IEC 61131-3 is designed to provide uniformity across all compliant PLCs that follow the standard. The IEC 61131-3 standard is to PLCs what ECMAScript is to JavaScript. In other words, the best way to think of the standard is as a set of rules that govern the programming interfaces for PLCs from different vendors. As such, by learning the rules on one device, a developer can easily port their knowledge over to another compliant device with relative ease. As such, the overall cost and time it takes to develop a PLC program will drastically decrease, as the developer will not have to learn a new programming syntax.
It is important to understand that just because a PLC follows the IEC 61131-3 standard does not mean that the code is cross-compatible. As stated before, PLC code is generally not cross-compatible. A program written for an RSLogix device will not run on a Beckhoff device. This is mainly due to the hardware architecture, the compilation process, and so on. However, considering that the device is compliant, the code can be ported over by creating a new project, copying the code into the new file, and tweaking the code to meet the requirements of the new device.
The IEC 61131-3 standard is not a language, as inexperienced PLC developers sometimes confuse it with. The IEC 61131-3 is simply a set of rules that compliant PLCs use for developing software. Not every PLC is 61131-3 compliant nor does every 61131-3 compliant PLC utilize every feature of the standard. Common IEC 61131-3 compliant PLCs are as follows:
- Beckhoff
- Wago
- Allen-Bradley
- Omron
- Siemens
This list is by no means an exhaustive list and the available features will vary from brand to brand. There are many more PLCs that are compliant. For the most part, all the major PLC manufacturers are 61131-3 compliant, especially for their newer devices. However, if you need to ensure that the device is compliant, all you have to do is simply check with the manufacturer. Usually, compliance is posted on the manufacturer’s website.
Adopting the standard is not a badge of quality, and non-compliant PLCs should not be viewed as inferior to PLCs that are compliant. There are many PLCs that do not follow the standards that are excellent and reliable devices to work with. Many non-compliant devices also share similarities with the standard at the basic level. However, due to the interoperability of IEC 61131-3 programming practices, using compliant devices will ultimately cut down the overhead cost of education. As such, compliant devices are usually favored for industrial automation projects. However, it should be noted that compliant PLCs will often cost more than non-compliant PLCs.
What does the IEC 61131-3 standardize?
Now that a little background on the IEC 61131-3 standard has been established, it is important to look at what is governed. The biggest aspect of PLC programming that IEC 61131-3 standardizes is language syntax, data types, and supported programming interfaces (programming languages). If you’ve ever programmed an RSLogix PLC in ladder logic, Structured Text, or another interface, and then programmed an Omron, Beckhoff, or other compliant PLC, you may have noticed that the general syntax, data types, and so on are very similar. Usually, the only programming components that vary are things like function blocks, as many function blocks are just canned functions that were built and included in the programming environment by the manufacturer. In other words, the gross similarities are the standard at work.
Recently, the IEC 61131-3 standard introduced what is known as object-oriented programming. It can be argued that the introduction of this concept is quite revolutionary as it means that the advanced techniques that are used to develop traditional programs can now be applied to the realm of automation. If you are familiar with a language such as C++, Java, C#, Python, or any of the modern traditional programming languages, you are most likely familiar with object-oriented programming. As such, understanding object-oriented programming for PLCs will be as easy as learning the syntax since the same rules apply to PLC programming. However, if your background does not include object-oriented programming, the principles that govern the paradigm will be explored in detail later, starting in Chapter 6.
Programming a PLC – The five IEC languages
The IEC 61131-3 standard includes several different types of language interfaces to program a PLC. In short, you can choose from multiple interfaces to program a PLC. These interfaces are akin to different languages, and each of the interfaces has its strengths. Some of the interfaces are graphically similar to what you would find in a system such as LabView, while others are text-based and akin to what you would find in a programming system such as C++ or BASIC. In the way the 61131-3 standard is set up, all the systems are compatible with each other, meaning that whatever can be done in one interface can also be done in another, and modules such as functions written in one interface can be used in another. The five IEC languages are described in the following sections. Let's take a look.
Ladder logic
If you are reading this book, chances are you know ladder logic and you know it well. Ladder logic is the unspoken standard for programming PLCs. Ladder logic was the programming interface that was developed to allow programmers to program in complex relay logic circuits without the need for bulky hardware or miles of wire. Of all the ways to program a PLC, ladder logic is probably the most common. To be a PLC programmer, a basic understanding of ladder logic is required.
Ladder logic is an excellent and very important PLC programming interface. However, ladder logic does have some drawbacks. Those of you that have had to program complex systems, such as systems for motion control, complex state machines, or the like, know that Ladder diagrams can easily become an unmaintainable nightmare. Ladder logic is an excellent tool for relatively simple applications or for beginners who are just starting their journey. However, as software becomes more complex and new features such as machine learning become more integrated into everyday automated systems, ladder logic is going to become an increasingly difficult tool to work with.
Sequential Flow Charts
Similar to ladder logic Sequential Flow Charts (SFCs) are another graphical tool for programming PLCs. However, instead of SFCs simulating relay logic, they allow programmers to essentially program a PLC using flow charts. SFC is best used to program processes that can be broken down into steps. SFC allows complex programs to be broken down into smaller modules and govern the flow between the modules. The big advantage of an SFC is that it graphically shows the flow of a program. This is a great advantage for developers who are working on process-driven projects.
Function Block Diagrams
The Function Block Diagrams (FBDs) interface is the final form of graphical programming language supported by the IEC 61131-3 standard. Much like SFCs and ladder logic programs, FBDs are a widely used language for programming PLCs. The core benefit of FBDs is that they can be used to simplify the programming of closed-feedback loops as they mostly work off of inputs and outputs and can provide feedback to themselves. For most IEC systems, the blocks are interconnected with lines that represent the flow of data from one block to another.
The FBD language is an excellent language choice for developers who are working on high-level projects. For example, suppose you’re working on a PLC program for a water treatment plant. You may have a process called water intake, water purifier, and collection process. As the developer, you may already have the functionality for these processes and as such, it is your job to string them together. For applications like these, it is very easy to employ FBDs to diagram out the process as a means of programming the PLC.
Instruction List
Instruction List, or as it is more commonly known, IL, is a text-based language that is governed by the IEC 61131-3 standard. IL is an offbeat language that is not used much in PLC programming. Users have to turn this on as a feature in CODESYS. The language itself is similar to the old Assembly language.
IL is arguably the most unpopular language in the IEC 61131-3 standard. It is complex to use and requires acute attention to detail. It is very easy to create an infinite loop, computational errors, and so on. It is also extremely difficult to debug. However, programs written in the IL language are generally considered quicker and require less memory. The language has all but fallen out of favor and should only be used if necessary.
Structured Text
Structured Text is arguably the second most popular programming language in the IEC standard. Structured Text is the closest to a traditional, text-based programming language that can be used to program a PLC. The syntax draws heavily from languages such as PASCAL and Ada. Many of the PLC programmers that I have encountered in the past have always seen Structured Text with a bit of fear. However, Structured Text is nothing to be afraid of. In fact, Structured Text can actually make things easier. Anyone that has ever had to sift through hundreds of rungs of ladder logic code will know that it is often difficult to figure out which rung does what and get a grasp on the overall flow of the program, especially when the code is poorly documented and there are many jumps used in the program.
In short, Structured Text will be the way of the future. As PLC technology progresses and applications become more advanced, Structured Text will gradually become the new standard in PLC programming. In other words, the days of simply turning machinery on and off at certain intervals are quickly coming to an end. The modern world is edging into complex machine learning and motion control, which means that it will be difficult, if not impossible, to fully implement these new, complex systems solely in ladder logic. Though it is possible to implement new concepts, such as object-oriented programming, in ladder logic, SFC, FDB, and so on, it can be awkward. Overall, due to the rising complexity of new automation systems, it is well worth the time to learn Structured Text and the advanced functionality that it provides.
Structured Text is the language that is going to be the focus of this book. To get the most out of this book, you should have a basic understanding of Structured Text. However, Structured Text is pretty easy to follow, as it is a simple, human-readable format. The examples in this book will be advanced Structured Text concepts but they will be easy enough to follow. If you feel that you do not have a great grasp of Structured Text, I recommend reviewing some basics such as loops, if statements, switch statements, and basic data types to get rolling. You will only need to have a loose grasp of these concepts to begin with.
As can be seen, there are many different ways to program a PLC. Now that a background in the different PLC programming languages has been established, we can begin experimenting with some basic code. To do this we will need a development environment. The development environment that we will use is called CODESYS.
