I spend a fair bit of my time upgrading older control systems on process and packaging equipment. There is a careful balance between doing enough to put a machine back into operation and executing a wholesale controls upgrade.
While I might dream of just scrapping all the old stuff and replacing with new, I am very cognizant of the investment that my employer has made in the inventory of equipment over the years, and I try my best to extend the life of the hardware, wherever possible, but with an eye to an easy transition to newer technology if and when it finally breathes its last breath.
Also read: So long, Remote I/O, and thanks for all the connections
A good example of this approach would be to put a current generation PLC or PAC in a control panel but retain the digital control of the variable frequency drives (VFDs) in the system. Unless there is a clear benefit to upgrading the VFDs, they might last for five years or more before needing replaced.
Our operations people get the benefit of a faster control system with current-technology operator screens while keeping the variable frequency drives doing their thing. Should they start to fail, we have the option of installing a new drive but retaining the digital control or, my preference, making a few programming changes and migrating the new drive over to the control network, thereby gaining all the benefit of control on this platform.
A blend of old and new doesn’t necessarily need to be so complicated, and the concept of continuing to use fully functioning hardware that has long since been paid for is certainly a happy benefit for the upper management.
With most of the complete upgrades we execute at my place of employment, we are checking off multiple advantages in one project.
The decision usually starts as a decision to rid ourselves of control systems that either have an obsolete PLC or have no PLC at all. It’s hard to imagine in this day and age, but we have many packaging machines that still run on plain old relay logic. Most of these, however, come from a time when ac voltages were common in the control cabinet.
Usually, if the PLC is out of date, so is the operator interface and the variable frequency drives. With these factors as a base, we can easily identify the low-hanging fruit that are candidates for an upgrade.
With a career of more than 30 years, sometimes our work comes back around to visit us more than once. Case in point, while still with my previous employer, I was involved in a vendor-executed upgrade of some older vertical baggers to what at that time was a good solid programmable controller, the venerable Allen-Bradley SLC 5/05.
This project was carried out in 2004 at a co-packer in Illinois. My employer, at the time, was based in Canada. It was a great opportunity to watch an OEM execute an upgrade. This activity was part of a larger project of starting up a new packaging operation that incorporated re-purposed equipment from a number of other packaging plants scattered around the country. I had the pleasure of seeing this project through from its very early concept to the startup of multiple packaging lines, covering the entire process from bulk product delivery and batch mixing to primary and secondary packaging, as well as finished packaging through palletizers and off to the distribution center.
Well, as life sometimes goes, I left that company and moved to my current position. To my surprise, the vertical baggers that I had worked on at that packaging facility found their way to me in my new position, the victims of a replacement program at that other facility.
The control systems were still good, and we’ve enjoyed many years of use out of those machines over the past eight years or so. In fact, as a result of the steady behavior of these upgraded baggers, we decided to take some of our own very old baggers—same brand—and put them through an upgrade process.
The new group are of the latest technology, and we like them so much that we have had seven of them upgraded in the past 18 months. Much like the upgrades I witnessed some 15 or 16 years ago, the OEM came in and made it all look easy.
I’m telling the story in this meandering way to explain that I’m not the only one that tries to minimize the financial impact on these necessary controls upgrades by keeping as much of the properly functioning hardware components as possible. It turns out those bagger upgrades I participated in all those years ago kept the original pneumatic components from the base machines that were manufactured back in the 1970s.
Still good components, they were even retained in the upgrade package that we executed less than two years ago. The latest rendition of the upgrade, executed just four months ago, finally let go of the old manifold and solenoids in favor of a newer technology.
This exercise in upgrading has really emphasized where we have come in pneumatics technology. Much like the PLCs, operator stations and drives that I often write about, pneumatics have taken the same path forward, in that they are smaller, faster and easier to implement.
A good example of the progress can be seen in the physical size of our original equipment 10-station manifold. The manifold takes up pretty much the entire width of the packaging machine, nearly 30 inches of real estate. The new manifold takes up about one-third of that footprint. Advances in valve technology mean you can push more volume of air through a smaller package.
Older manifolds required individual outputs on the PLC to control each valve. Double-ended valves required two outputs. It is easy to imagine that multiple-PLC modules would be needed to control the pneumatics on a machine.
One great step forward has been the integration of fieldbus technology into pneumatics. You can connect control of the valve bank via your favorite control network and free up all those modules in the processor architecture. Additionally, since it is a fieldbus, most manufacturers incorporate I/O modules right on the manifold, eliminating the need to run separate wiring for I/O and pneumatic purposes. Since it is a fieldbus, you can use any module that you might use in a traditional PLC rack, but it can reside on the machine instead.
As it happens, one of the first-generation upgrade machines—the ones with the SLC 5/05 processors—has been misbehaving lately and we’ve narrowed it down to an issue with either the wiring from the valve base to the PLC or a problem with the connector in the valve base itself.
While the PLC is old, it is perfectly functional, as is the rest of the control system. The valve bank is from an older generation and has lasted well past reasonable expectations. We reached out to both the OEM of the bagger and the OEM of the valve base. Both are willing to help with components, but parts are not immediately available.
At this point, the story comes full circle. We’ve got a still functioning control system but one of the base elements, the valves, are in need of an upgrade. For those who aren’t too familiar with a SLC 5/05 processor, this was the last in the SLC series and is capable of Ethernet I/P communications, but the ability to connect using an add-on profile is not possible in this vintage processor.
Fortunately, we can purchase the same valve base that we have on our latest three bagger upgrades but will order it with a wired base interface so that we can control the valves using the existing PLC output module.
All of the advantages of the faster, smaller valve technology will be present, including the ability to stock common replacement parts and still retain the control via the older PLC technology. Should we want to upgrade the PLC, operator station and/or drives in the system, we don’t necessarily need to start from scratch.
This “nearly there” approach to equipment upgrades gives the ability to get past some worrisome, near-failure situations on multiple pieces of equipment, rather than spending the same capital on a single controls upgrade.
Fortunately, hardware vendors are starting to be more aware of the need to integrate old and new technology in a graduated implementation and providing convenient means of making this happen for the end user.
Final word: I don’t normally mention specific hardware platforms and have found that the subject matter contained in my articles can be applied to readily available hardware from most popular vendors. However, I came across something recently that I do want to share, one warrior in the trenches to another.
A few years ago, my favorite hardware vendor, Rockwell/Allen-Bradley, made a decision to move away from supporting older technology platforms, in favor of newer offerings. With the release of RSLinx version 4.00, the ability to use RSLinx to upload/download to the older PanelView Classic operator terminals was dropped. I’m sure there were other hardware that similarly dropped but this one impacted me greatly as I still have a large installed base of this workhorse of an operator terminal. I do understand the reason for doing this. It must be hard to manage multiple communications protocols in an “everything in a package” software like RSLinx. Like everyone else out here in the trenches, I found workarounds. I would uninstall version 4.00, or later, and install version 3.99, make my changes and then reverse process, ready to work on the latest processors and hardware again.
For those who know me personally, you can imagine that I didn’t take this issue lying down. I can be a bit of a pest when it comes to things like this, and I complained to just about anyone who didn’t hang up the phone on me. Sadly, I thought I was fighting a losing battle, and I just accepted my fate, as well as the repeated software cycles any time I had to work on the older equipment. Well, much to my surprise, I discovered quite by accident that there has been a change in direction, and the newest version of the RSLinx software has restored the download via RSLinx functionality. I’m not sure if it was just the latest version—I’m not dogged enough to chase it down—but I am thrilled that it works! To be honest, I forgot about the restriction and clicked the download button in the old PanelBuilder software without even thinking about the loss of function.
What a great time to celebrate.
Somewhere along the line, RSLinx became FactoryTalk Linx, for those of you who might have been wondering what this old programming guy was rattling on about.
