Hardware Trace Buffer aids in performance tuning

Here’s the scenario: Your motor jogs in 16.8 mSec, but the spec calls for 15. You suspect that the servo parameters aren’t optimized, but you’re having trouble determining what’s going on inside the motion controller. Solving this problem calls for a high performance data capture system, and many off-theshelf motion solutions provide some form of this important capability.

The gold standard of data capture and display is known as a hardware trace buffer. Compared to older polled approaches, hardware trace guarantees synchronicity, and is limited only by the size of the on-card trace buffer. Here’s how it works: before capture begins, the user selects which parameters are to be traced, usually as many as four at a time. Then the user specifies the capture event, much like a trigger on a traditional oscilloscope. Once trace starts, the motion processor loads the specified parameters (synchronized to its own cycle time) into a RAM buffer for later retrieval and analysis. Variations on this theme include rolling storage mode, where the user continuously reads as the motion hardware continually writes, and a programmable stop trigger.

The other major choice for the motion processor is to purchase a DSP (digital signal processor) or microprocessor and program the motion functions directly. This approach has the advantage of lower cost, not only because most DSPs are less expensive then dedicated motion ICs, but because if the application is simple enough, it may be possible to eliminate the need for a separate microprocessor that contains the host code. Combining the host code (the code that controls the overall machine function) with the motion processor function has drawbacks. Motion processors generally require high speed, synchronous attention to motion peripherals, while the host code spends much of its time servicing communication requests or determining the next action. Combining the two functions does not always make for a reliable and responsive system.

Another factor is motor type. Programming a servo loop is complicated, and relatively few designers attempt this themselves. Getting the micro to generate pulses through a digital I/O port is simpler, so if the application uses a step motor, a home-built motion controller may be a good option.

On top of these product design considerations however, it is important to consider overall project costs as well. Off-the-shelf motion chips result in a shorter development cycle because the design effort focuses on the application itself, rather than the low-level motion routines. In addition to this, motion IC vendors provide developer’s kits for their products. These products contain PC-based cards along with programs and software tools which save time, because they allow members of the design team to start working earlier. The software engineer can start writing motion sequences early on, while the mechanical engineer can prototype different motors and linkages before the application motion card is available. Once the application motion card is ready, the code can be hosted on the actual user-developed card for final integration and testing.