Automation Fair in Chicago was a great event for those of us who live and breathe Rockwell Automation-based controls platforms. It brought together a large group of partner vendors who make products that work in direct concert with the Rockwell brands. There was a notable increase in the areas of software products with serious advances in the area of manufacturing execution systems (MESs), computerized maintenance management systems (CMMSs) and enterprise management systems (ERPs).
It might be suggested that the years-long pandemic and the injury to the supply of physical hardware provided software developers with a convenient way to bring their products to the forefront. A dwindling labor force only amplifies the need to use non-physical methods to enhance the existing workforce and retain these resources in what is becoming a very competitive world.
If I was to summarize my overall feeling coming out of this event, I was most impressed with the degree to which the Strategic Alliance Partners have embraced the core elements of the programming environment to make their specific product offerings easy to deploy in a controls package. The offerings from the various vendors and services make it very hard to resist adding new technology to your next design.
Over my 35-plus years in this business, I have had a front-row seat as technology has marched through time. My first exposure to programming was with a very early model of the Omron programmable controller. While primarily based on ladder logic, I quickly caught onto the use of the pneumonic editor to quickly put code together. Windows-based operating systems were in their early stages of development and getting an “examine ON” or “examine OFF” instruction into the development software was much easier if one learned the keyboard shortcuts for these instructions.
The next step in my journey took me into the world of Allen-Bradley. The platform of the mid-1980s was again with a disk-based operating system (DOS) on a dedicated programming terminal. Function keys were assigned to specific instructions and anything beyond the default eight function keys involved navigating further down the menu keys to bring up more complex instructions like timers and counters.
When the development software started to move into the world of a graphical interface, I was already well entrenched in the use of pneumonic representation of instructions and, to this day, still resort to that from time to time to quickly get some code into my software routines. A keyboard string like “XIC XIO OTE” is much easier for me to lay out in the software than grabbing the instructions off a graphical toolbox and dropping them onto a rung in the program.
Similar experiences in the late 1980s and into the 1990s gave me comparable exposure to Siemens and Modicon programmable controllers and their programming environments.
Many of my earlier adventures were with control systems for packaging equipment. Machines of that vintage were easily handled in a ladder-logic format and made for easy troubleshooting for technicians who were taught the basics of reading and interpreting that graphical programming format.
Like everything in our world of control design, technology advances and the need to do something more elaborate takes us in new directions. Such was my experience with Siemens, as that was my first exposure to a programming language called statement list (STL). I likened this method to deconstructed ladder logic as one could literally take a ladder of code and deconstruct it into the pneumonic representation of that rung of code. However, statement list was much more than deconstructed ladder logic because one could perform complex math functions using STL that simply could not be done with plain old ladder logic. My first forays into processing, rather than discrete machines, helped me to understand why this method of programming was essential.
Rewind this story about seven years, back in my college days, I was also compelled to take courses in some other programming languages. GW-Basic—who remembers this oldie but goodie?—led to Pascal, C, Prolog and other similar languages. These can all be lumped together loosely as a programming technique called structured text (ST).
I really dove into these opportunities with more vigor than perhaps was expected because I really did see these higher-level languages as the key to my future in controls and automation. I spent hours of my own time in front of my home desktop writing silly little programs to do things like generate random numbers for the lottery, control traffic lights or the lights in the shed out back.
I even had a course that guided me through the duplication of the venerable Space Invaders game on a Commodore PET. Little did I know how much these early geek experiences would serve to advance my career over the past three decades.
Down the road of time there have been stops at Basic, Visual Basic, C, C+, C++ and HTML, to name just a few. While these experiences were on specifically designed hardware platforms, automation products have dragged these programming languages right into the heart of our automation controllers. No longer the venue of the IT professional, structured languages have become increasingly useful in designing and implementing program algorithms.
A good example of where we have found ourselves in the the transition from 2022 to 2023 is evident right here at my place of work. We have a large inventory of packaging machinery that can be best described as a trip down memory lane from the 1960s to the latest and greatest equipment with current technology.
While we are aggressively trying to phase out the earlier technologies, we can still find a few Idec smart relays, SLC-500s or early Logo and DirectLogic PLCs. The common denominator for all of these was the use of straight old ladder logic.
As we have upgraded these older units, usually because we can’t buy spares any more, we didn’t find any reason to migrate away from ladder logic even though the newer programming languages are readily available as a method of programming. What we didn’t consider is we have been using stand-alone control components to take care of some of our more complex control elements where those functions could be incorporated into the programmable controller with the bonus of better control over these key elements.
One of these often-overlooked parts of our machines is closed-loop heat control. We use heaters and thermocouples with a stand-alone loop controller to seal bags and pouches. While these stand-alone units work reasonably well, there is a limit to what one can do with this technology; and some of our more sensitive packaging materials needed something a little more than we could provide.
As often happens, we learn about newer technology and techniques when it arrives on new equipment that we purchase. Heater control was one of those situations. We bought a new pouch-making machine, and, instead of the usual array of seven stand-alone loop controllers on the face of our operator station, the interface was graphical on the operator screen and the closed-loop control was contained in a PID-loop function block provided by the PLC manufacturer and adapted for use by our equipment vendor.
While we were impressed by the performance of this technology, we were disappointed to learn that our standard programming software package didn’t include the language pack to open up the magic inside the protected function block. This was our first exposure to the need to see more, and we quickly realized that some of our other equipment, supplied in the past five years or so, also had protected language code blocks. We were blissfully unaware of them because we hadn’t needed to troubleshoot the element being controlled.
So, where does all this lead us? The fact is programmable logic controllers (PLCs) or programmable automation controller (PACs) have the option to be programmed in one or more programming languages, all at the same time in the same controller. The advantage to the end user is third-party vendors can develop algorithms to work with the hardware products and the control designer can add these components as linked libraries to the control design.
Further, we aren’t locked into using ladder logic, with the built-in limitations. The selection of which programming language can be specific to the function being controlled.
Another impact that this open programming architecture is providing is the all-inclusive nature of being able to program in the archaic ladder logic for the old folks, like me, or in newer Visual-Studio-type structured text languages for the young pups. The end result is algorithms that are more suited to the type of control system one is designing.
Complex math functions can happily fit in along with a simple ladder program. The question becomes, “What do we choose?” The answer really is whatever you want. Ultimately, one should decide who is the user of the machine or service you are providing? Choose a programming language that suits the application but also suits the people that are going to look after your creation after it leaves your shop floor.
