Balloons, they seem like a simple product. I can’t imagine anything being difficult about sealing a couple of layers of plastic film together. Well, that’s what I use to think before I was asked to build a machine to make foil balloons. Over the last 17 years, I have been involved with the design, manufacture, and installation of these machines. They weigh in at about 10,000 pounds and are 30 feet long. A large percentage has gone to customers outside the United States. Each installation comes with its own challenges. When they are international, those challenges can be significant.
A few years ago on an installation in Central Mexico, I ran into a problem I’d never encountered before and at the time struggled with what could be causing it. This was the first sale to this customer and my first visit to their facility. Things weren’t going as planned, the machine wasn’t running. The customer was asking why, and I couldn’t explain why or what I was going to do about it.
These machines have a servomotor to index product underneath a number of seal heads. Each index has a controlled stop using optical registration of the film to position the pre-printed images under the seal heads. I specified the components, wrote the software and had done this many times before. I thought I knew the equipment inside and out and yet randomly the machine had a hiccup with the motion. Sometimes, the index speed would be off, going too fast or too slow. Other times the index length was wrong. Every hiccup seemed to be different without pattern. Every time this would happen, the very next index seemed to be fine. It might happen every 5 minutes or only once an hour.
I spent a day monitoring the in-coming power, looking for power anomalies to explain the malfunction. I went through every electrical connection of the machine thinking somewhere I would find a loose wire that could account for the random nature of this problem. I contacted the drive manufacturer, hoping they would tell me about some firmware revision that I wasn’t aware of and point me in a direction. I found nothing and at this point I had a machine that didn’t work, limited resources and the customer breathing down my neck.
It was getting toward the end of the third day and still no real clue with what could be wrong. I had the display (Operator Interface) disconnected from the servo to use the serial port for my laptop and had been monitoring the drive most of the day. It was then that it dawned on me that the machine had run without incident all day with the display unplugged. I plugged the display back in and sure enough about 5 or 10 minutes of running, and there it was. I left the display unplugged for the next shift as a test and the machine preformed perfectly without exception.
Ok, so now I had a clue where to look. Like most I instantly thought; I have a noise problem. This particular display has two serial ports. The second port was talking to a PLC, and that didn’t seem to have any problems, but that is far from a definitive conclusion. I didn’t have equipment with me to monitor the data stream. So I really couldn’t prove or disprove that noise was there or a problem. My experience with industrially hardened components is that if you follow some basic “best practices," noise is seldom the issue. I ultimately decided I would have to dig deeper, and got the customer to agree to run the machine as is (display disconnected) until I could find a solution to the problem.
After returning home, I made a number of calls to both the display and servo drive manufacturers. In conversation with one of the drive firmware engineers, I was asked the interval between data transfers from the display to the drive. I had to check and according to the data sheet, every 500 milliseconds. After discussing the amount of data I was transmitting, he told me that was probably too often. It was concluded I was overflowing the serial buffer. I had used this display / drive combination before, but previously it was just for data display. In hindsight, earlier installations probably had the same problem, but they were easy to overlook when the machine performance wasn’t affected.
After thinking about it further, it all made sense. The machine checks every cycle for motion parameter changes and recalculates the motion profile based on those values. When an overflow occurred, data was lost and the register being written to only received part of the data. Then the program would use that corrupted data to calculate the next move. There’s little wonder why the problem manifested itself in such a random manor.
The fix ended up simple; reduce the polling frequency of the display. I have used 10 or 15 different brands of servos over the years. I have used even more brands of PLCs and operator interface units. For the most part, I have had little problems integrating various brands of components, but when you run into compatibility problems seldom will you find the answer in the supplied manuals, you’ll most likely have to dig deeper.
Mike Frazier is vice president of Axis Automation in Hartland, WI. For most of the last 30 years, Mike has been designing and building automation equipment for numerous industries. In the beginning of his automation career, he worked as a machinist, serving an Apprenticeship at Centerline Industries in Waterloo, WI. In those early years, Mike took an interest in the control side of his projects. Since that time, he has developed controls systems based on PLCs, Motion controllers, PCs, and embedded controllers as well as combinations of those platforms.