PLC Upgrade: The pros outweigh the cons

The Peak Materials migration from GE PLC to Allen-Bradley

About three years ago, Peak Materials decided to take matters into their own hands. The Colorado-based supplier of industrial ready-mix concrete, asphalt, and other aggregates had been in business for more than half a century. But they were hearing from other companies in the industry that the GE PLCs that Peak had been using in their equipment for decades were not ideally suited for this line of work and were becoming increasingly problematic to service and support.

Coincidentally, it was around this time that Peak received a call from Quantum Solutions Inc. (QSI), checking in on whether Peak was happy with their current PLCs. After some discussion, an in-person assessment, and a subsequent quoting process, Peak hired QSI to tackle a full conversion from a GE PLC and 2 remote IO racks to the more modern Allen-Bradley 5570 CompactLogix PLC.

Challenges in the Mountains

The outdated GE PLCs used a couple of remote racks located in different parts of the quarry-like complex. In order to complete this conversion, QSI needed to communicate with those racks from the main hub. In a typical conversion, the engineers would simply connect via hardwired Ethernet/IP communications, but it was clear from the outset that the distance between points was too far for Ethernet. Therefore, the original proposal called for the use of radio communication using wireless Ethernet radios. But now that QSI was on the ground, their engineers’ concern grew that the heaps of rock and dirt dotting the landscape—some as tall as 50 feet—might obstruct the antenna communications.

A quick pivot to beat the clock

Fortunately, QSI’s engineers quickly came up with a new plan on site. The engineers decided to run fiber-optic cable through the same conduits that much of the old GE cables were running through. This use of fiber was still new to the QSI engineers, but they had done their homework for just such an occasion. After having to use a welding torch to thaw the metal conduit that held the old cable still frozen in the ground, QSI engineers worked with a long-bearded independent local electrician named Ray that Peak had brought in to pull the fiber and proceed with the conversion as planned.

Finished with time to spare

An extra day and a bonus job

Always there when needed

Typically, a conversion the size of this is a once-every-couple-decades expense for a company like Peak. And now that they’re running a state-of-the-art Allen-Bradley PLC and back crushing stone and cranking out concrete and asphalt, the Colorado firm is better prepared for expansion and growth. They likely won’t have much regular need of QSI’s services in the near future.

But as far as QSI is concerned, that isn’t the point. They were brought in to do a job and they performed beyond expectations in terms of both scope and timeframe. In the process, they got to know more about Peak’s industry and came to feel like a part of the team. The engineers also developed new tools and skills that they’ll be able to put to work for future clients, whether it’s Peak or another company in need.

The COVID-19 outbreak is reshaping lives and neighborhoods. As a company unreservedly committed to our employees, our customers, and our communities, QSI is doing everything in our power to minimize its impact.

Informed by expert advice, we are taking actions that comply or even exceed CDC guidance – all to keep our workforce and surrounding communities safe.

Our social distancing, sanitization measures, and working from home are all steps that will help flatten the curve. So too will aligning with our clients’ individual risk minimization requirements and expectations when on-site.

We realize that manufacturing businesses are experiencing unique challenges. Constant communication is essential to help our customers succeed during this difficult time. As a nimble, adaptive company, we will always find ways to meet your changing needs while putting safety first.

Right now, this means shifting to remote and automated solutions:

Remote access.
Diagnosing and solving issues from afar doesn’t need to be challenging. Our secure remote access capabilities empower us to quickly, safely and efficiently analyze and solve emerging issues to support your team. We can get customers started with hardware that can be connected and configured remotely, allowing us to troubleshoot and provide support while adhering to social distancing guidelines, and even across the country. With remote access, projects don’t need to stop. Even if a site is running on a skeleton crew, or is restricting personnel access for safety reasons, you can still progress by proactively laying the groundwork keep things running smoothly.

Production support. Due to COVID-19 many plants are running with reduced personnel. Some may also face challenges sourcing OEM equipment technicians. As industrial automation experts, we can help fill these gaps experienced by manufacturers nationwide. We are also more than happy to serve customers within driving distance. We stringently adhere to customer’s individual risk minimization guidelines, conducting our business safely and efficiently while on-site.

Ad hoc problem solving. QSI exists to solve problems. We offer tailored solutions to meet business and production challenges as they arise. Many customers currently face unprecedented demand, running overtime as production ramps up. Using our real-time overall equipment effectiveness (OEE) diagnostics, you can minimize waste and maximize yield. We can also help customers future-proof their businesses with solutions that maximize output, minimize human error and automate repetitive tasks. The outcome is better ROI and improved overall worker satisfaction.

We understand that COVID-19 is changing the way the nation lives and works, and we are here to support our customers every step along the way. We are actively reaching out to customers, and invite you to speak to us about solutions to help troubleshoot or maximize output during times of restructure and change.

Hi there, welcome back. This is the second part of an interview I did with Atomic Revenue about the difference between Legacy Controls Migration and Controls Modernization. Read the first part, which included references to video games, the growth mindset, and data analytics, here.

Quick summary: Legacy Controls Migration is getting an old system up to the latest and greatest hardware and software, to avoid downtime in case of failure. Controls Modernization is a separate project to take advantage of new functionality for higher efficiency, greater reliability, and better analytics, among other aspects.]

AR: How does that set you up for the future? If you complete a major modernization project now, when might you need another? Is it two years? Five? Or could you say that if you did it right, you won’t need to have that same kind of transformative modernization project for a significant amount of time?

QSI: I would say after modernization they are good for a significant amount of time. A lot of these systems that they’re upgrading are 20, 30, years old. And they’ve worked fine to that point in time. But now as things get more competitive, if they want to stay ahead of the curve, you know, they may not want to wait another 30 years. You may continue to upgrade along the way, which is easier with more scalable control systems. You see that a lot, in these old systems they’ve added devices over time to better control the process. They say “We want to rewrite this whole thing, because along the way we’ve added this, and this, and this conveyor offshoot, and this burner, and it’s made our process better, but it was pieced together.”

Things kind of get disorganized. We call it “spaghetti code”, and it becomes very hard to manage. But the structure of programs now is so much better and so much easier to manage, which is another benefit that you wouldn’t think of as obvious. It’s having more structure to your programs, better organization and your controls are laid out in a much more logical fashion. Documentation is much better, too, so you’re not losing descriptions in your programming, and all that consistency makes your maintenance more effective. Because what was written before, by, say, potentially 10 different operators as they added to the code, now is rewritten with by an experienced engineer with structure and organization in mind. We’ve reimagined the whole system and there is no need to be diving into the programming all the time, because it works.

You know, I’ve described that process where you have something that works, but you need a new function, so you just stick something else on to the side, I’ve called that the Frankenstein method. “We’re just going to add this little thing here, we’re just going to work-around that there, we’re going to add one other feature here,” and in the end it’s almost unrecognizable compared to what you started with. But it does kind of the things that you need it to do, yet you’re fighting with it all the time and it doesn’t really behave. It sort of takes on a mind of its own at times. So you occasionally need to hit the reset.

People who think like that are growth-minded people. We like working with those kind of people. Those are your facilities that are more likely to modernize. The ones that have been driving constant change as new technology advancements come out, and have been saying, “Hey we can improve this?” Or, “This is a process that’s broken.”

Often they’ve done an adequate job as they’ve grown, they’ve improved along the way, and the last piece is for them to take the next step and modernize. They need to rethink it all integrated together in the way that it works now, which is so different than the way that it did 30 years before. Those are the customers that are fun to work with.

The ones that put in a system 30 years ago and it was very limited and they didn’t really look to change it, as new technologies came out, they didn’t add on new functionality, those are the ones that are more likely to be about just mitigating risk. They are more likely to say, “Hey, give me the same thing in a new system, I don’t care to modernize.” So that’s your two different types of mentalities, and typically one of the factors that decides between migration and modernization.

That first mindset is the growth mindset, the second mindset is “I’m just going to do my job, and I don’t want anything to break along the way.”

Yeah, and that’s why I say it’s not completely a cost thing. It’s not just cost, it’s cost plus that growth mindset versus risk mitigation. Those are the two factors, and which is the right approach is going to be different for everyone. Because, if you were satisfied with the system you had, and you just didn’t want it to go down, you really wouldn’t want to spend the money on rewriting, adding bells and whistles that you don’t care to use. It’s the difference between a growth mindset and a “Hey, this works, don’t fix what isn’t broken.”

In terms of helping with planning, obviously small, medium, and large projects are going to have different time frames for each one. What might be some minimum and maximum estimates for those, how long it would take from start to finish?

If you’re doing a simple migration, you have a small system and you just want to get to the latest and greatest hardware or software platform, usually you’re looking at about four to six weeks of engineering time, which might not always be linear. That’s usually we’re handing over the keys of exactly what you had before. There’s no differences, there’s just an upgraded hardware platform on the back end. That’s a small timeline, and we would just do the design, work on the migration, update the code, and then go out and do the testing and training. There’s not usually a whole lot of training on that, so about four to six weeks of work for an engineer and now they don’t have the risk of failure and downtime.

If you’re going into the modernization, usually, you would look at that differently, like I’ve said many times, as if it was a new project. So a small system, for example, we’ve done a project for a sucrose tank system. There’s a three-tank sucrose skid that basically receives sucrose from trucks, supplies its own header, keeps its temperature, maintains pressure, and that’s about it. It lets other systems pull and open a valve to deliver the sucrose to another process. This is a small, enclosed system with a few racks of I/O [Input/output].

You would do a sequence of operations on how it’s supposed to work, you would do a design to incorporate the I/O into the control system, you would write the program, you go onsite and test out the I/O, and then test the functionality. Usually a couple of days of support and training with the operators and you’re out. Smaller system like that, maybe an additional six weeks of engineering time to get that done, once you’ve completed the migration.

For more mid-sized systems, like sand filters, of which we have a case study, that’s a bigger and more complex system. Four tanks, with detailed multi-step sequences, like the backwashing skid, and a lot more equipment, but the control is mostly repeated. The control, the functionality, the visibility is all shown pretty much the same on each tank, which makes it a little simpler. We could modernize a more complicated system like that, in a few months worth of time. About double the time, but potentially completed in the same time for the calendar with two to three engineers.

Then you could get into big, multi-line systems, like the cookers, and the flour mills, those are more in the four to six month range. When it came to the cookers, that was a 7-line production floor with tote dumping, cooking, cooling, oil coating and tank storage. The flour mills project had hundreds of devices integrating into multiple processes, with many different control loops. All these different processes all put together in one line, those more complicated systems you’re looking at more like a four to six month modernization with several engineers on the job.

This has been a very enlightening discussion. What else do you think people should know, to take away from this conversation?

I just want to point out that, in addition to all that we’ve discussed, there’s often a pretty clear case for a positive ROI on modernization projects. You can justify the spend by integrating different data history and visualization packages that prove out better consistency, increased productivity, and reduced maintenance troubleshooting. Sometimes it’s easier to see ROI justification for a migration, you know, improving to the latest and greatest hardware and software, and minimizing the risk of some dollar amount of lost production time. The improvements, though, in the modernization phase, are all about the upside. There’s a lot of potential that may not be quantifiable at the outset, but will be clearly evident after the project is in place and better decisions are being made, better efficiency is demonstrated, and reduced costs are dropping to the bottom line.

Thank you!
Very welcome.