The intent of this article is to bring awareness to the matter of speed and how it can be addressed early in a project rather than being surprised somewhere during development or worse yet commissioning.

Have you ever been bitten by speed in delivering an automation project?  How do you determine whether speed is going to be an issue in an automation project?  What do you look at to determine speed constraints?

I would venture a guess that most, if not nearly all, of those reading this blog will have been challenged by some speed constraint in their past projects.  In my own history I have had more than one occasion where I have had a “collision” with speed.

So where might you expect speed to be a problem? I always look at packaging lines with a cautious eye.  Communication interfaces can have an impact on batch execution or order downloads or usage uploads or data collection, etc. Servos, vision systems, batching systems, machine control can all have their speed challenges.

There may be elements in any packaging line that challenge the limits of classic PLC control.  On one occasion, we had a need to manage accumulating bi-flow conveyors on a packaging line.  That didn’t seem too challenging at first until I discovered what window I had to work with in counting the packages in and out.  Not only did we have to manage the accumulating conveyors, but we also had to collect the data to a server for production reporting.

The packages were flying by at such a pace that it was going to require a high speed counter in order to reliably capture the counts.  The high speed counter was running asynchronously to the PLC scan as was the server also running asynchronously to the PLC scan. Keeping track of the high speed counter in the PLC wasn’t too much of a problem but getting the proper count to the server required a hand-shaking routine to make sure we didn’t miss an exchange or double up on a transmission or even handle a loss of communication for a short time.

On another occasion, I was pulsing a collection of hose connections to determine what was connected to what and lost track of (forgot to consider) the slew rate of the output card and the input card. In other words, from the time you tell an output to go high how long does that take to reach full voltage? Then how long does it take for the input card to see that signal. Then how long does it take for the PLC scan to see that resultant input signal? How much margin do you need in order to be certain that you’re going to be able to see that exchange every time it happens? Remember that these things are happening in addition to scan time. Then you also have to consider the reverse sequence and the time that takes. In my case I was getting phantom trips and could not for the life of me catch onto the idea that I was outrunning myself in this “pulse-scan” effort. Maybe once or twice a day I would get a phantom trip. Finally a colleague of mine asked whether I had considered the slew rate (perhaps this is an old term but you get the idea). I finally resorted to some basic engineering and ran the numbers to only find that my problem was entirely self-inflicted.

On another occasion, we had a packaging line with a vertical accumulator. The line speed was such that when we ran the numbers, it was obvious that without a dedicated controller we weren’t going to be able to actuate the accumulator stop between boxes. (don’t forget to allow for the solenoid reaction times and at what air pressure) The result was to apply a dedicated controller on the accumulator and simply manage it as a separate machine on the line.

Cycle times on batching systems can also be challenging. Rates and purge times are not the only constraints. If you need to have data exchanges with a server, how responsive will the server be and what are you using for a communication link between the primary line controller and the server?

Another example was a machine that was applying a wrapper to a container. As line speed would change, the machine cutoff action needed to be adjusted as well. The problem was that the amount of resolution required was beyond the timing resolution of the PLC. We ended up having to mount the detector on a fixture that would allow us to adjust the timing by moving the registration eye via a stepper motor.

If you’re not an experienced motion control resource, it’s easy to assume that a servo can handle whatever you throw at it, but you should test your theory as soon as possible or even invest in a test scenario before committing to a solution.  Inertias and accelerations and accuracies have an influence on one another.  Proper sizing is also very important and beware of safety factor.  A servo that is oversized for the application isn’t as good as it might first sound.

Vision is another technology that should be closely examined not only for the lighting, lens and all the visual stuff but also speed.

My recommendation is to always look at speed (sensing; timing; communication; acceleration; …) as soon as you can and then run the numbers. Make sure that you have a solution that falls within the speed constraint. That should just be part of a sound Project Methodology.

Ray Bachelor
Chairman of the Board