It’s hard to admit it, but perhaps we do get more complacent with time and resistive, perhaps ignorant, of change. After nearly four decades in this compelling industry of controls and automation, a lot of knowledge and experience is crammed into this old brain of mine. I have always prided myself on keeping up with technology, and I am always scanning the myriad emails I get each week extoling the virtues of the next greatest thing from my favorite vendors.
After the scramble around the pandemic to get parts to complete controls projects, I would have to say that I am significantly more open to considering products that wouldn’t have been on my radar even months before. With all the buzz around tariffs now, I wonder if we are, once again, going to find ourselves opening up our choices to the realm of possibilities from previously unrecognized sources.
As it happens, this is a very busy time at my place of employment. We currently have four major capital projects on the go with startups scheduled for January through September of next year. These are exciting times for our controls team as the projects are new production lines and heavily automated.
Building structures are being modified. New utilities are being deployed to service the production space. Integrating all the various parts is a huge endeavor that is elevated by the fact that we have multiple projects on the go at the same time.
We are a small group, and, like many small companies or integrators out there, we rise to the challenge when a bigger project comes in. We have great successes in our past endeavors and try to do each project better than the one before. An essential part of this is to be aware of advances in technology and utilize them in our designs when they make sense.
A great example of technology helping a design came in the form of a newer generation of programmable automation controller (PAC) from our favorite hardware supplier. This new generation has been out for nearly two years now, but, aside from finding them in some vendor-supplied equipment, we really haven’t taken a close look at the product because our existing generation of PAC is still actively available, and it does everything that we’ve asked it to do.
Our interaction with the newer generation came in the form of simply having some bits to exchange back and forth with our line control panel so we could tie all the various unit ops together and do some data collection for our OEE software package.
At first glance, the newer PAC looks mostly like a cosmetic change to what I would call more of a European look with removable spring-load terminals. However, the real changes are inside the package.
Compliance with the IEC 61131-3 programming standard necessitated a change in some of the traditional ladder-logic instruction mnemonics. For newer programmers who are accustomed to clicking an icon to insert an element into a software design, this change might not even get noticed. However, for those of us who have been around for more than 20 years or so, this change is quite uncomfortable.
For example, the traditional GRT (Greater Than) is now GT. LES (Less Than) is now LT. These might seem like ridiculously insignificant changes, but for those of us who have programmed by entering text on a line, the change is like learning to speak French when all you know is English, but having to do it in a few hours.
Fortunately, or perhaps less fortunately, the vendor provides an “automated” way of upgrading a software application that was created in a previous firmware revision to this later hardware and firmware. The surprise was that the transition forward converts most of the application but flags the “old” instructions as not being recognized, instead of just going ahead and updating them.
One larger program that I recently migrated to the new firmware/hardware resulted in nearly 1,000 instances of an instruction that I had to manually navigate to and convert to the new instruction.
Another surprise was the dropping of some traditional instructions and changing them over to function block (FB). One example is the SCL (Scale) instruction. For someone without previous experience with FB, this would be a very big surprise. Further bumps in the road happen if your software platform is a legacy version—for me, that was just 14 years ago—where FB, structured text (ST), instruction list (IL) and sequential function chart (SFC) were not part of the original hardware platform but were added in the ensuing years. That surprise resulted in having to purchase further licenses in order to include that feature in our base of installed software development laptops. This isn’t as important if you are just troubleshooting but hugely important if you are developing new code.
In our usual control design, we pick our favorite model of PAC with the favored firmware level installed and then include a safety relay in the design. The hardware vendor makes that part even nicer by having an interface module that connects the PAC to the safety relay using Ethernet/IP. It turns out most of the safety relays can communicate across an optical bus that is already built in. Just add the comms module, and you can get status from the channels and nodes on the relay plus have control over the outputs on things like door latches.
Get your subscription to Control Design’s daily newsletter.
This brings us to a big feature in our newer PAC platform—the ability to include a safety processor with the logic processor. For sure, this is not that new of a feature but if you are happily building controls using the now mature generation of PAC, the thought would not even come to mind. In fact, our experiences, thus far, with the new generation of PAC did not expose us to the embedded safety controller.
During the process of working out the integration for our newest production line, we learned that several of our equipment vendors will be providing the dual-processor PAC in their designs. Curiosity, they say, kills the cat and there we were diving down the rabbit hole to see what all the fuss was about. To find out that our hardware vendor is offering safety and non-safety PACs at the same price pretty much sealed the deal for us.
The financial gain by buying a PAC with a safety controller included was significant. The comms module and safety relay are fairly expensive on their own. Taking that cost out of the design was a bonus, as was being able to use the same safety devices that we were using previously. There was no reason not to change.
When using a dual-processor PAC, one adds slices of input or output modules that are specifically for safety. They are even colored red to differentiate from normal I/O modules. The slices only come in eight-input or -output versions because the safety devices are two-channel. If desired, we can use a field-mounted interface module that communicates on Ethernet/IP with the safety controller.
Where one might use the IO-Link type safety network and nodes with the separate safety relay, the field interface module provides a means of connecting the M12 terminated safety channel directly to the module and, thus, to the safety controller in the PAC.
Programming with a safety controller is less complicated as we simply wire up each of the safety devices to a channel on the safety I/O module and use software to create the combinations of inputs that will produce an outcome on a channel on the safety output module. With the safety controller being part of the PAC, we also have a direct connection with the safety outputs that form the dual channel Safe Torque Off (STO) feature on our servos and variable-frequency drives (VFDs).
The only caveat that we found in our experience with the PAC/safety controller was that our programming software, yet again, didn’t have the safety programming module enabled on it, and, yet again, we were back to the vendor to buy licenses for the computers that will be developing code for the safety side of things.
There is a price, it seems, for hanging on to legacy hardware and software for too long, even if it is still available from the hardware vendor.
Teething issues aside, working with the PAC/safety controller has been an eye-opening experience for us. With six out of the 10 units of operation on our new production line coming with the dual processors, we decided to jump into the fray and designate one of these newfangled things for our main-line control cabinet. The ability to program both the main control algorithm, as well as the safety zones and devices of our line, with the same single point of connection and program application has us placing a whole new emphasis on this approach as a default direction for us in future projects.
With three other production lines going in within the next nine to 12 months, we anticipate some good practical experience to go with our decided path. We already love it, and we don’t even have the panel built yet. The off-line design and development of the software application is already seeing a savings in time and money.
