We create and control motion. Our machines don’t care much whose controllers or controls components we use. The unique part, the proprietary part, is in how we put together these motions to make the overall system more efficient, more reliable, smaller, less expensive, and easier to maintain.
We’re not servo nutso. We look for the best value. But we do use a lot of servo axes.
We just shipped a side-seam carton gluer/bag-in-box cartoner/case packer/palletizer that’s 50 feet long, sits on a single frame, and relies on a single PC to control 36 axes of servo motion. Is that single Windows-based Pentium PC as robust as a PLC? No. Largely because the PLC doesn’t have Windows on it. Let’s face it, any time you have an operating system that’s Windows-based and people can load programs in, how can that be as stable as that black box of a PLC over there? But the gap in robustness between a PC-based system and a PLC-based system has been greatly reduced.
What we encounter now is that if a packaging machine is going to have a PC on it, as long as it’s only handling HMI and SCADA, 99% of customers are fine with it. But if you are going to have machine control and motion that are PC-based, the acceptance dips to 35%. We think it’s important to look at it from the right perspective. Does the 36-axis machine we just shipped rely on one PC? Yes. But if you look at a conventional line, all those unit operations have to be done by something like 13 processors. Three of them might be PCs, and the other 10 are PLCs. What is there about that scenario that says anything like “robust” or “stable?” Granted, the PC in an industrial setting might be considered less robust than industrial PLCs. But the PC isn’t 13 times less stable. Once the customer looks at it in those terms, they begin to see things in a new light.
We think the best thing for us and our customers is to promote open standards. If it’s not open, sorry. We had a technology provider in here lately that makes great drives and motors. But they don’t support SERCOS. We asked them to come back when they do.
Openness is so important. One of the technology suppliers we work with supports 13 different bus systems. With their controls architecture, I can have a CANopen ring with drives on it, a SERCOS ring with drives on it, and a Profibus ring with drives on it and I can synchronize electronic camming among all those drives even though they’re on three different communications protocols. The rings are deterministic, as any good motion these days is. So they’re putting data into my controller every two milliseconds. All I have to do is bring all this data in, look at it, compare where all these drives are compared to my master. Then I send out signals telling the slave drives to be where they’re supposed to be. Whether or not you’d ever really want to do that is beside the point. The point is, you can do it because of how open it is.
We think PackML and the state model are good ideas. But the state model isn’t very complete. I’m also a bit concerned that our implementation of it isn’t very consistent with other packaging machinery OEMs’ implementations. I’m hoping Make2Pack will bring more consistency. After all, doesn’t the whole PackML idea revolve around all implementations being the same?
Customer awareness of the PackML State Model doesn’t seem all that high. I don’t have customers coming to me and saying, “Do you have the State Model incorporated in your machine control?”
If OEMs are going to get involved in Make2Pack and really get invested in it, I’d like to have some assurance that it gains critical mass. Why not start a consortium and raise some real money from end users? I’d suggest $100ęŻ from each end user. Those who sign on first should put down $10ęŻ , and that money should be invested on getting others involved. If we can’t get a dozen or so, then those who signed on early would be relieved of the remaining $90ęŻ commitment. If we get the dozen we want, we’ll still need a sizeable volunteer commitment. But we’ll have some money to move things forward, to help get that critical mass.
I’ve been frustrated on occasion by the technology providers. Their decisions are not made to benefit automation in general. Their decisions are made to improve the bottom line or make stock holders happy. Who can fault them for that? But still I’d like to take all the energy spent trying to understand all these different software platform languages and focus that energy on creating software standards. Then we packaging machinery OEMs could spend our time and creativity creating motion and mechanisms. A piece of software doesn’t move anything. It has to be coupled with a physical device, and it’s the physical device that creates motion. Our ability to create motion is what’s going to help us compete against packaging machinery OEMs now emerging in China.
