Beware of any programmable logic controller (PLC) vendor who claims that IE C61131 is the magic bullet for programming. Choosing the right PLC to control your chemical production is more complex than that. PLCs are the controlling brains in most automated processes. If not a PLC, then it is most likely a computer. Without these, the process is most likely manual, which is then less repeatable and heavily reliant on people to do the right thing at the right time.
The Role of PLCs
Since the early days of PLCs, manufacturers have worked toward a common programming language by adopting standards such as the IEC 61131. While PLCs all basically work the same, each manufacturer’s software accomplishes its goals slightly differently. In addition, selecting a PLC based on the programming software or some specific desirable hardware feature doesn’t account for the support available for customers programming and using the controller. All of this must be considered when selecting a PLC. Additionally, IE C61131 doesn’t mean there’s no learning curve.
The holy grail of the PLC world is program-less PLCs. But that’s really an oxymoron, as it would reduce programmable logic controllers to simply logic controllers. It would also eliminate one of the PLC’s most powerful strengths: flexibility. Every application is different with different logic, and machines often evolve even after they’ve been delivered to end users. Simplified programming is great, but that invariably comes with limitations in the logic and capabilities. A more attainable and equally attractive goal should be common programming that is the same for similar products from different manufacturers.
The Quest For PLC Standardization
What really makes programming challenging is when every product has a different language. To make it more perplexing, there are several different types of controllers (PLC, motion, PC-based, etc.) that all have different programming philosophies and needs. However, they heavily overlap in capabilities and ability to be used for the same applications. So, the next best step is to have every controller use the same language. But haven’t we had that for decades with all the PLCs that use Ladder Logic? Yes, but that is just the PLC world. What about the motion control world? While many motion controllers use similar languages, they are still different with their own commands and syntaxes. And then, there are the various PC-based programming philosophies with graphical and object-oriented methods. This involves the use of the IEC61131-3 standard languages, which encompass not only Ladder Logic but also Structured Text, Function Block Diagram and several other options. But, IEC 61131-3 only pertains to the programming method and doesn't encompass the PLC's capabilities.
For a controller to support any of the five languages, the programming software must have a built-in engine that translates these languages into a common base code that the controller will understand. However, the software interface around the engine can vary from manufacturer to manufacturer. To illustrate, consider an Excel spreadsheet for calculating interest on a home loan. Excel is the engine, but an internet search for “home loan calculator” will generate dozens of spreadsheets that accomplish the task in slightly different ways.
Controller programming software is similar: The end goal is the same for all platforms, but the programming varies for each PLC vendor. For example, some PLC manufacturers may not have a common human-machine interface (HMI) and controller combination. Or they may use different software packages to program them, and it’s often unclear how well those two packages work together.
Software Development Environment
An additional factor to consider is the programming environment used for developing the controllers. Usability can vary significantly between manufacturers, even if the controllers have similar controls.
For example, think about trying to use a Mac OS if you are Windows user or a Windows OS if you are more familiar with an Apple. The controls are, at least in many ways, the same, but the environment (“menus”) is different. How a user starts a new program, enters new instructions, creates tags and adds libraries may look very different from one supplier to another. These environmental differences were particularly obvious when different controllers used different languages. However, they did not go away – even between controllers that standardized on the IEC 61131-3 languages.
Meanwhile, PLC manufacturers are continually updating their products using the same language and basic capabilities as previous versions but with newer features. This means even a single vendor applying the same language and capabilities to a new generation of controls could present a vastly different operating environment for a user.
PLC Technical Support
Something is easy if you already know how to do it. For the rest of us, there are user manuals, help files, online forums and technical help. This is where the idea of “sameness” between manufacturers starts to break down. The availability of readable documentation or access to a knowledgeable person can save many hours of development time. Think about poring through thousands of pages in multiple documents to search for the answer to a simple question. Now, imagine doing that several times in a programming session. This is another area that can differentiate two very similar controllers.
Open Automation
Aside from the IEC 61131-3 languages, there are other efforts in motion to make PLCs even more cross-compatible and “open” for the next generation of automation controllers. Some PLCs are based on Linux or other operating systems, so the programmers can use whatever language they would prefer to use, such as C#, C++, Python, etc. Chemical processing companies need to ask themselves at what level the “openness” is focused and always whether the level of openness seems too good to be true. The IEC 61131-3 languages are one level of “openness” and are based on an industrial standard that took many years to develop. Linux is a completely different level of “openness” initially developed outside of the industrial world. When considering an option, consider what needs to occur to make open automation a reality.
Consider Your PLC Resources
If you are considering automating your chemical process, you most assuredly need a controller of some kind. That will most likely be a PLC. Consider who is going to install, program, implement and support it. Knowing the programming background of that person will help you know which controller options to consider. Then, be sure to consider who will support the system a year, five years or even 20 years down the road. You may not be there to deal with the issues, but the person who is will thank you for your foresight.
