PW: How can Plug-and-Pack reduce end users’ tendency to impose their own controls preferences on machine builders?
Martell: When we do this, we can’t really leverage the machine builder’s previous design work. Each project becomes a new adventure from the OEM’s point of view, so they’re limited in their ability as to what they can deliver to us. Of course, from the user’s perspective, there’s the counterargument that if I give away too much of the design decision, how do I guarantee that I support this system? In some way those big, thick specification documents provide users with a certain comfort level.
If we have some standards [such as Plug-and-Pack] that both users and OEMs can accept, then we can be more likely to accept the OEM’s standard automation platform. The users involved in Plug-and-Pack are trying to pull in the same direction as machine builders. A common standard, once agreed upon by both parties, can be used to alleviate some of this very detailed specification.
As an example, on two recent projects, I accepted a fieldbus that I wouldn’t have accepted two years ago. It was one that was recommended in the Plug-and-Pack guidelines. I know it’s going to be affordable long-term, and that it works for the application the OEM chose, so why should I force the OEM to change? Two years ago I would have requested a different bus, and it would have had a big ripple effect on their design, requiring them to change their software and control—all a tremendous disruption for the OEM.
I’ve been faced with that same type of decision at the controller level, evaluating a machine with a controller that’s not in the company standard list. But it complied with the Plug-and-Pack guidelines at every level, including network architecture, software, etc. So after analyzing it in that context, I knew there was no reason not to accept that controller, and I did.
I’m sure not all users put the same amount of value into the Plug-and-Pack guidelines that I do. I personally know the quality and diversity of the people contributing to it. They’re having an impact on my buying decision, benefitting the OEM and me. And it results in shorter lead times, because on these two projects I did not feel compelled to redesign the OEM’s control. Every job’s going to have some amount of customization for a specific package, or application. If you can avoid doing a brain transplant on the machine, [you avoid] the kind of thing that adds months to a schedule.
PW: Is Plug-and-Pack all about servos?
Martell: That’s where it started, but 90% of the work that the Plug-and-Pack group has done can benefit any machine that has some level of automation. It’s really about how you create an environment where you get the most out of your automation. I’m recognizing that most of this stuff has nothing to do with servos. It has to do with the machine design process.
PW: How can machine builders benefit?
Martell: First they need to become familiar with the work that’s going on. Those OEMs that are not currently implementing standards need to think about doing so. Once implemented, a control system that complies with Plug-and-Pack guidelines can be used to defend the OEM’s control platform of choice. Say a customer comes in and says, I’d like to buy your machine, but I’d like you to quote me with the blue control instead of the red one. If I were a machine builder, I’d turn it right around and say, I could quote you the blue one, but here’s why I picked the red one; here’s the list of Plug-and-Pack guidelines; and here’s the group of thought leaders in the packaging field that looked at it and said it’s good for packaging applications. —DN
For the news from the recent Plug-and-Pack meeting plus a link to the guidelines themselves, visit: packworld.com/go/w060
See sidebar to this article: Reducing pharmaceutical validation costs
