Return to the Industrial Control and Automation Index
Let’s start with a recognition that this is a complicated and, at times, contentious topic. I have yet to meet a person who did not have strong opinions about the “best” programming language and what students of Programmable Logic Controller (PLC) should and should not know.
This article is my best attempt to provide a balanced introduction. Your assistance would be greatly appreciated. You can help improve this article by leaving your comments and suggestion in the space below.
Figure 1: This Crouzet EM4 PLC with integrated display is running a classic “Hello World!” program.
What is a PLC?
A PLC is an industrial computer designed to control industrial equipment and processes. On the inside, the PLC is controlled by a mid to high-end microcontroller. This delicate logic is isolated from the harsh industrial conditions using optocouplers, stout semiconductor output drivers, and relays.
The PLC may be a compact all-in-one or modular design with purpose-built modules with function such as outputs, inputs, and analog. The largest of these PLCs would include modules that expand to the right occasionally resulting in a PLC that was nearly 2 feet long. In all cases, the PLC was matched to the task based on the speed and computational power of the CPU along with the specific Input / Output (I/O) needs of the machine or process to be controlled.
This definition still holds in principle but is growing increasingly outdated. The problem, or should we say, future, is the interdisciplinary aspects of the PLC and greater networking capability demanded by modern processing. It could be said that “Industry 4.0” is changing how and what type of PLCs will be used as increased networking capabilities are required. We must also consider the availability of increased processing power. This allows vision capability that would have been unheard of when that original definition was hatched. We should also consider the possible applications of deep learning using tools such as TensorFlow.
The resulting definition of a PLC might be more appropriate stated as: A PLC is an intelligent networked platform designed to control industrial equipment and processes. With the stipulation that there is a tremendous variance between a simple stand-alone machine and the collection of networked PLC used to coordinate a factory.
What languages are available?
Traditionally, the gold standard PLC languages were defined by IEC 61131-3. This includes:
- Ladder logic (LL)
- Function Block Diagram (FBD)
- Sequential Flow Chart (SFC)
- Structured Text (ST)
- Instruction List (IL)
The graphic interfaces with LL and FBD were welcomed by technicians who could quickly determine the state of the PLC by observing the icons. A representative ladder logic code is shown in Figure 2. This Modicon PLC program is used for single pushbutton control of a process. For a different perspective, Figure 3 presents a Crouzet PLC featuring a mixture of FB and SFC blocks.
Figure 2: A ladder logic program implemented on the Schneider Modicon PLC.
Figure 3: The debug window for a Crouzet PLC featuring combined FB and SFC blocks.
The changes in processing power coupled with networking and powerful vision techniques allow, or perhaps demand, changes in programming languages. We also need to recognize that PLC programmers are often being minted from computer science programs. These programmers have their own set of expectation about what an industrial computer should and should not do.
A fascinating counter example to the traditional PLC is produced by Revolution Pi (Kunbus). This device certainly meets the traditional definition of the PLC as explored in this deep dive into the PLC hardware shows. It also meets our revised definition of flexible network. Finally, it is an attractive platform for the computer science majors.
As implied by the name, Revolution Pi is built around the popular Raspberry Pi processor. With some limitations on latency, the resulting machine has a wide range of applications. As an ironic example consider Video 1. This is a recent visit to the Raspberry Pi factory. At time index 7:25 we see the Raspberry Pi based Kunbus PLC used to make additional Pis.
Tech Tip: Latency is a term used to describe how fast a PLC may respond to a real-world event. Traditional PLCs with high speed I/O, coupled with an internal high-performance interrupt driven microcontroller, and properly programmed are likely the best solution for high-speed machine control. However, this is a niche application. Many machines and industrial control process are viable with latency in the 10 to 100 ms range. Also, purpose-built modules may be better suited for control of the high-speed process. An example is a motor drive with encoder to control the rotational velocity. The PLC need only send high level (networked) commands to the drive as opposed to handling the ms-by-ms control.
If we allow the Revolution Pi to be categorized as a PLC, our language options grow considerably. PLCs such as the Revolution Pi can now be programmed in nearly any language that will run on top of the Linux operating system. This includes traditional languages such as C and Python. The 61131-3 languages are available using extension such as CODESYS. There are Arduino-like programs that will run on top of the Pi. Programs such as MATLAB are viable. On top of this there, software environment management tools such as Docker are available.
Video 1 The Raspberry Pi based Kunbus PLC is used on the line to make additional Raspberry Pi computers.
What PLC programming languages are considered mandatory?
Let’s shift gears and temper the software enthusiasm with some hard facts:
-
Understand that the PLC is a tool. It is designed for industrial control and automation. Consequently, it is directly tied to the bottom line of the company.
-
Things can and will go wrong requiring technicians to restore the PLC based system to full functionality.
-
Down time, while technicians troubleshoot the system, will cost money. Every minute the line is down will cost in terms of lost opportunity in manufacturing widgets, idle time for the workforce, time and wasted materials to restart the process, and likely overtime to make up for the lost production. You also run the risk of losing the goodwill of customer.
The bottom line is that any PLC purchasing or programming decisions must be made holistically with due attention to the current and future workforce maintaining the systems.
It’s obvious that a tension exists between the grand desires of the programmer and the bottom-line requirements for reliable day to day operation. In no way am I suggesting that we abandon advanced capabilities, but we do need to be cognizant of the system and multi decade life cycle of the system.
All programmers must be adept at ladder logic!
Let’s take a closer look at the technicians and how they interface with the equipment in the factory. Suppose we have PLC based system that has been commissioned and operation for a long enough time to work out the bugs. Would you agree that the majority of technician troubleshooting time is dedicated to wire, connection, sensor, and actuator problems? Would you also agree that software is low on the list of probable faults?
Assuming you agree with the two previous statements plus the previous bottom-line constraints, you must agree that thinking like a technician is a high priority.
Technicians think in terms of ladder logic because that is the world they live and work in. Technicians troubleshoot the systems surrounding the PLC using wire diagrams and ladder logic because that is the language used to describe industrial machinery. The majority of their time is spent chasing problems external to the PLC.
In my opinion, any would be PLC programmer must understand ladder logic. This is a practical reality requiring a working knowledge of how the PLC is physically bolted into the greater system. It’s also a necessary to have a common mindset – a written language - with those who will service the system.
Tech Tip: The concept of Intellectual Property (IP) and liability complicates the programming argument. In an ideal world every technician would have access to the PLC and software development tools. This is not a reasonable assumption as there are times when you as a programmer will protect your IP. For some PLC development platforms, this code locking feature is the first step in starting a new program. There will also be times when you don’t want to give away the “keys of code modification” for liability and warranty reasons. Consequently, the PLC becomes a black box for the technicians. The only information they have is the built-in indicator LEDs (not universal) or the fault codes, text, or Built-In-Test (BIT) you coded into the PLC. This constraint further enhances the argument to learn ladder logic and have a common language with the technicians. Your bottom-line depends on it.
What are the industry trends?
This PLC discussion reminds me of the situation for microcontrollers. With all the new fancy 32 and 64-bit devices folks have predicted the 8-bit devices would become extinct.
No.
The 8-bit microcontroller is alive and well. In fact, the technological advances for the new devices is applied backwards to the older 8-bit devices. The results in an 8-bit microcontroller that are faster while consuming less power. There is an added benefit of increased usability for the software tools.
The same conditions apply to the PLC. It’s safe to say that the traditional stand-alone PLC isn’t going anywhere. It’s a solid performer that will be with us for many decades with replacement parts available from the Original Equipment Manufacturer (OEM) or second sourced.
In the same breath, we need to recognize that increased computation power and the possibility of deep learning has changed the landscape. It’s safe to say that new programming languages and networked software deployment techniques will become increasingly common.
Conclusion
Clearly, there is much to consider with regards to PLC programming. There can be no simple answer for a “best” one size fits all programming language just as there can be no one size fits all PLC. Instead, there nuanced considerations for each application.
May I encourage you to share your thoughts with our readers? What challenges have you faced? How did you persevere?
Oh, and don’t forget – speak the same language as your future technicians by learning how to program in ladder logic.
Best Wishes,
APDahlen
About the Author
Aaron Dahlen, LCDR USCG (Ret.), serves as an application engineer at DigiKey. He has a unique electronics and automation foundation built over a 27-year military career as a technician and engineer which was further enhanced by 12 years of teaching (interwoven). With an MSEE degree from Minnesota State University, Mankato, Dahlen has taught in an ABET accredited EE program, served as the program coordinator for an EET program, and taught component-level repair to military electronics technicians. Dahlen has returned to his Northern Minnesota home and thoroughly enjoys researching and writing articles such as this. LinkedIn | Aaron Dahlen - Application Engineer - DigiKey
Return to the Industrial Control and Automation Index