Carefully consider controller location.
Just as in real estate, think location, location, location! Controller location in the overall motion system is the single most important factor that can simplify, or complicate, a motion design. To determine the correct location of the motion control software and motion controller itself, engineers should ask themselves three questions:
-
Are the axes' motions synchronized with each other?
-
What response time is required to handle system changes?
-
How important is code portability?
Software architecture matters.
When it comes to motion controllers, so many different options are available that the choices can seem overwhelming. Just remember what really matters — the software architecture that will be used to control the application. Writing software in the host (typically this means a PC) is usually the most convenient, but it is the least time-responsive. On the other hand, putting all the software in the motion controller will likely give the performance you want, but can mean extra work, particularly if you must learn a vendor-specific motion language. Motion controllers are typically long on raw software horsepower, but short on support for standard computer languages.
Organize your control problem.
Consider a C-language-based motion controller so that software can be run on the host or on the motion controller, making repartitioning easier. Most importantly though, organize your control problem. Separate slower functions from high-speed functions, and make sure those high-speed functions reside in the motion controller. Data collection, display, and other data management functions can go in the PC.
Make sure your motion controller can handle worst-case scenarios.
Mechanics interacting with the motion controller can fail in some obvious ways, such as bearings becoming stiffer and servo parameters no longer working, but they can fail in subtle ways as well. Can your machine controller handle rare, worst-case events, such as the simultaneous arrival of a motion command, index pulse, limit switch, and the end of a motion? Expect the worst to happen and with luck, it won't. Test early and often, under as wide a range of load conditions as possible, and design with margin. Many an engineer has chased his own tail trying to locate a once-per-day, or worse, a once-per-week failure. There are no magic answers to these brain-bending problems, but making sure the machine can handle pile-ups of simultaneous events is a good place to start.
Focus on relevant specifications.
A common mistake made by engineers is focusing on irrelevant specifications. For example, selecting the fastest sample rate is often unnecessary, as a 1 kHz sample rate is sufficient for all but the smallest high-performance motors. A better approach: Think about the processing time required to perform your specific application's program.
Don't overestimate determinism needs.
Engineers often overestimate the requirements for determinism in system communications. Communication uncertainties of less than 100 microseconds are fine for nearly all motion systems. Tighter determinism rarely has any effect on overall system performance.
Motion controllers aren't magicians.
Systems engineers often think that motion controllers can compensate for a poorly designed mechanical system. While motion controllers can overcome some weaknesses like nonlinearity, they can't compensate for gross mechanical errors such as low-frequency resonances, undersized motors, mechanics with large dead bands, and spring-like couplings.
Avoid common grounding.
A common mistake that engineers make is to have a common ground and supplies on both sides of the optoisolators. If it's the same ground, it isn't isolated. The filtering effect engineers think they are getting from isolation is really the low-pass effect due to the slowness of the opto.
-
Choose the right motion controller for the job.
Specifying the wrong type of motion control is a common issue. However, picking the right tool for the job can save both initial costs and engineering time. For example, many single-axis applications can be performed using the on-board motion control available in the digital drive. The same is true of simple point-to-point multi-axis motion. Using the on-board motion can save a lot of money and programming complexity, because you can use a less powerful PLC as opposed to a PLC with built-in motion.
-
Know the warning signs of impending failure.
Typically, performance issues occur at higher speeds or higher axis counts. For example, some controls start losing performance after an engineer adds a 10th axis, requiring another processor be added. This leads to issues regarding the close coordination of the axes connected to different processors, as well as the cost of the additional processor. The warning signs begin to appear when the designer tries to increase the speed of the machine: He or she will start to see missed parts, inaccurate positioning, and other anomalies. When using intelligent digital drives, this issue goes away, as the drives each carry their own position loop, thereby reducing the load on the main motion processor.
Industry expertise
Tips 1 through 4 submitted by Chuck Lewin of Performance Motion Devices. Tips 5 through 8 courtesy of Wayne Baron of Galil Motion Control. Tips 9 and 10 provided by Joseph Biondo of Festo Corp.
Chuck Lewin • Performance Motion Devices Inc. • (781) 674-9860 • www.pmdcorp.com
Wayne Baron • Galil Motion Control • (800) 377-6329 • www.galilmc.com
Joseph Biondo • Festo Corp. • (631) 435-0800 • www.festo.com