Rimrock Corp., a supplier of automation equipment for die casting, faced a problem: How to respond to greater customer demands for improved performance through greater precision and higher part counts without scrapping millions of dollars of installed equipment. The Columbus, Ohio-based company solved the problem by installing an Ethernet-based control system that uses a small programmable l...
Rimrock Corp., a supplier of automation equipment for die casting, faced a problem: How to respond to greater customer demands for improved performance through greater precision and higher part counts without scrapping millions of dollars of installed equipment.
The Columbus, Ohio-based company solved the problem by installing an Ethernet-based control system that uses a small programmable logic controller from Schneider Electric. The compact control system is now used on all new Rimrock equipment, and it also allows legacy die-casting machines to be easily retrofitted to address marketplace demands. The bonus for customers is the savings. Compared to purchasing a new piece of equipment, a control system retrofit of existing machinery costs upwards of 60% less.
To learn more about Rimrock's decision to go with an Ethernet-based control system, Control Engineering 's editorial director, David Greenfield, spoke with Dave Woods, controls product development manager at Rimrock.
Q What was the initiating factor driving this project?
Purchasing first brought it to everyone's attention by mentioning that a key supplier was going to stop making a board that we were so dependent upon. So it was an obsolescence issue that started it all.
I was hired to get the project going. I got a budget, a timetable, and a big stack of wish list items to implement.
Q How many different options were considered?
We looked at an awful lot of products. Several camps existed in the company at the time, and many just wanted to rebuild the system (an STD bus system) with new parts. I was personally on board with going to a PC/104 controller as a replacement. So we had PLC manufacturers come in. Also, one of the main issues evident on our wish list was connectivity. So we paid a lot of attention to vendors who could connect to other things.
At this point we were in a technological stalemate between the different camps. A couple of smart guys can get together and have differing opinions and really slow down the process. It's important to try and avoid these stalemates, because all of the proposals we saw would have worked. But you've got to go with your gut feeling. I came from a background heavy in PLCs and the reliability there is phenomenal, and I know that customers basically want a system that'll work 24/7/365. I went with PLCs because I knew I could sleep at night.
Q How did you learn about this system, and why, ultimately, did you choose it?
It really fit our cost constraints, and it gave us the Ethernet connectivity we were looking for. And when you boiled down all the wish list items, what everyone was basically looking for was Ethernet. It's the only medium I know that could possibly do all those things and handle our motion control. Not only did it offer us the connectivity that we needed, it also gave us a really good platform to do programming and debugging and put us in the mainstream. We were using embedded controllers and that was something of a closed-end deal. Everything that we put in there we had to create—software and some hardware. With the new system, we wanted to call it the "Otis" system because we could suddenly use all these off-the-shelf [OTS] components.
Q Did you face any hurdles internally?
From the Ethernet aspect, I really didn't have any hurdles. Everyone here knew that Ethernet was going to become a big player in the control market and that all the things we want to do we just wouldn't be able to do with anything other than Ethernet—at least not with our cost constraints.
The switchover from an embedded controller to a PLC, however, met with some resistance. Some wanted to keep it closed—not wanting customers to know they could buy equipment from their local supplier.
As engineers, we do a lot of research and experimentation, and basically we're paid to make decisions that fit our application the best. But there are always going to be those who want something different.
It just goes to show how much each engineer's decision impacts everybody in the whole corporation. So it's very important for us to do our homework and have our ducks in a row when somebody comes and asks: "Why did you do this?"
Q Did you experience any problems with implementation of the system?
As for implementation hurdles, every customer is different, and people want to do lots of different things with this Ethernet cable. Some want service capabilities, so our guys can just call them up and troubleshoot the machine. Others want to collect data—we have a little SCADA package we've constructed using Visual Basic that provides a nice front end for anyone who would want to do back-office monitoring or back up memory areas (recipes for parts, set-ups).
The biggest implementation hurdle we face is getting customers the infrastructure they need to do what they want. To guys that want networking, we've got to explain how to put in that network and what they need; to guys that just want to take a laptop out every now and again, we have to make sure their laptop is ready to go. Then you've got guys that don't want to do anything. They just want to set the machine in there and have it do what it's supposed to do.
Q Looking back, what would you say were the most important lessons you learned from this project?
When you open up a new way of doing things, especially one as big as Ethernet, you really find out how much more you need to know. You need to know Visual Basic, Java, and HTML. You've got all these new skill sets you've got to get your people trained on, and that's something I probably didn't anticipate and was lucky that we had a couple of guys on staff who knew how to do this.
There are always people who recognize the value of new technologies and the capabilities it can bring, and then you've got the people who want to know in dollars and cents what this is going to do. Engineers tend to get on a project, get excited, and sometimes lose sight of the fact that the end result must be that we make money and the customer makes money. Ultimately that's what we're here for.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.