Even though software is the undeniable driving force of today’s data analytics, it still has to run somewhere, and must take in and relay information to other physical locations. All of these jobs require cables, connectors, sensors, instruments, I/O, PLCs, DCSs, servers and other hardware, and they’ll all require installation, configuration, troubleshooting, maintenance, repair and replacement sooner or later.
For instance, Varland Plating in Cincinatti, Ohio, is a job shop that’s been bulk electroplating automotive, aerospace, electrical, firearm components, consumer parts, fasteners and other products for 80 years. Though historically, mostly manual, its barrel plating process includes: controlling barrel rotation speed and direction with variable-speed drives (VSD); tracking parts moving through the plating lines and their time at each step; maintaining precise vat temperatures, fluid levels and pH conductivity settings; managing automated chemical feeds; and applying and tracking precise electrical currents with a rectifier that facilitates electrolysis.
To perform these tasks efficiently and product quality products, Varland started automating them in the 1990s, when its engineers adopted Opto 22’s SNAP-LCM4 controllers, mistic racks with G4 single-point I/O, and FactoryFloor flowchart-based programming software. These solutions enabled the company’s objectives for decades, but the limits of its legacy hardware became evident over time.
“Every barrel on our automatic plating lines has a radio frequency identification (RFID) tag, and our hoists use serial RFID readers to help us track jobs through production,” says Toby Varland, technology VP at Varland. “Each SNAP-LCM4 controller supports a maximum of four serial ports. At least one of those ports had to be reserved for I/O, so we were limited to a maximum of three RFID readers per controller.”
Organizing I/O points
This traditionally limited number of serial ports required Varland to daisy-chain dozens of I/O racks on individual serial communication ports, and in some cases. expand the architecture to add additional processors. This setup led to increased communication latency, potential data collisions, and complicated troubleshooting, ultimately hindering system performance and reliability. Fast forward to today, where Varland reports that one GRV-CSERI-4 serial module on Opto 22’s latest groov EPIC system supports four serial ports, and a single EPIC processor can support up to four of these modules, resulting in 16 individual serial connections on one controller.
“Hooking up RFID readers to serial modules on EPIC lets us condense to a single processor per plating line,” explains Varland, who’s also noted the shift from serial to Ethernet networking and communications. “We could theoretically keep running SNAP-LCM4 processors. Most of our systems have been running reliably with serial for many years. However, newer groov products have so much more installation, programming and operator-experience capabilities that make it easier for our staff to do their jobs.”
Likewise, Varland also upgraded several thousand digital and analog I/O points one rack at a time without ripping-and-replacing components, and used a workaround to avoid a costly shutdown.
It used Opto 22’s Scratch Pad temporary memory storage area for data exchange between controllers and I/O processors, which lets users map EPIC’s I/O channels to internal memory registers that their legacy SNAP-LCM4 controllers can access. Open communication between legacy and new equipment lets them maintain the existing program on legacy hardware, while developing a new one in parallel.
“The control logic on the LCM4 doesn’t change,” adds Varland. “We can start developing a new solution on groov EPIC. For testing, I can flip a switch, do some testing, and then flip back to the old program.”
Get your subscription to Control's tri-weekly newsletter.
Help for homegrown historians
Thankfully, upgrading its 30-year-old control infrastructure enabled Varland to make its critical process variables available in a modern, Ethernet-based communications interface. However, this raised a new challenge—limited visibility and no long-term trend analysis. Subsequently, Varland used free resources to develop homegrown historian software. Using Opto 22’s open-source-friendly REST API, Varland deployed a suite of PHP command-line scripts that retrieve I/O and critical data values, and log them into an InfluxDB time-series database. The data is then visualized and contextualized using Grafana, an open-source monitoring platform (Figure 1).
While its DIY historian was a victory, scaling homemade data collection scripts is challenging. Plus, as the system grows, maintaining continuity is risky, especially if the original developer becomes unavailable. Consequently, they needed a scalable platform with professional support and documentation to ensure long-term SCADA reliability.
“Through groov EPIC, we learned about Ignition software, and we feel we can use it to accomplish many SCADA goals we haven’t achieved yet,” says Varland. “We started with an Ignition Edge license on one of our groov EPICs, and I liked it enough that we bought a full Ignition license that we now run on Apple’s Mac Studio server. InfluxDB and Grafana worked really well for long-term storage and trend analysis, but Ignition lets us remove the pain point of custom data collection, and allows us to use Ignition Historian as a passthrough to get data into InfluxDB more reliably and with significantly less work.
“Getting data into a historian platform, where we can be flexible about how we access and study it has given us new insights into our processes. We reduced downtime, improved our operator experience, and freed our operators to focus on parts and quality. No one doubts the impact, even though it’s hard to measure.”
Varland’s future plans include performing groov EPIC upgrades for several more automated lines, full migration to Ignition for HMI and SCADA, and exploring Codesys for IEC 61131-3-compliant PLC programming languages.
