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?

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.

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.

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.

Tips 1 through 4 submitted by Chuck Lewin of Performance Motion Devices

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.

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.

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.

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.

Tips 5 through 8 courtesy of Wayne Baron of Galil Motion Control