Get Moving

Test-and-measurement tasks often involve movements that fall into two general forms: moving a product or actuating a product. In the first case, think of a product that is too big to view all at once with an electronic camera. Inspection would involve taking an image of a specific area and then moving the product under the camera to inspect a different area. In the second case, manipulating the product could involve rotating a control during testing.

Feed me: A basic feedback loop lets a controller move a motor's shaft from one position to another. Think of the computer providing the required position and the position sensor providing an error-signal. The motor moves to minimize the error and stabilize its final position.

In both cases, designers must carefully apply a motor or other electromechanical device to turn electrical energy into motion. But there's more to moving or actuating a product than hooking up a motor to a power source.

In some applications, motion may take place independent of the test system. Think of spark plugs undergoing final inspection. A motor would rotate each spark plug so a line-scan camera could image the entire surface during one rotation. The motion controller would trigger an image acquisition at the start of each rotation, but the imaging system would not control the motion.

In many test systems, though, motion requires control, which usually derives from a computer and the software that runs on it. The trick comes in properly "connecting" the computer's test-and-measurement (T&M) tasks to its motion-control duties.

But to start, design engineers must plan how equipment will move, what will move, how fast it must move, what special fixtures the equipment will need, and so on. In some cases equipment under test will move, while in others, test probes and other test equipment will move. Engineers who lack hands-on motion design experience may need to call on experienced colleagues.

In Step: Two signals from an optical encoder connected to a shaft provide position and direction information. Note the phase difference as the encoder's shaft changes from CW to CCW.

Companies that supply motors and controllers can offer formulas, rules of thumb, and applications assistance for a specific type of design. Some manufacturers also may provide tutorials for newcomers to motion control. This sort of information helps narrow the selection criteria to those appropriate for an application. Specific characteristics such as torque, step accuracy, gear ratios, and others may require careful attention.

Trapped

When it comes time to specify motors and controllers, engineers can fall into traps. According to Al Ng, senior chief engineer at Danaher Motion (www.danahermotion.com), engineers have a habit of over-specifying what they think they need for an application. Ng suggests engineers outline their plans and organize their needs according to priority. Then they may find things that looked important aren't needed at all. Ng also cautions engineers to think in all dimensions, which include motions along the normal x, y, and z axes, as well as pitch, roll, and yaw, which may add capabilities not considered during initial designs. But they also can vex designers who fail to account for induced rotations along those axes during the normal movement of equipment.

When selecting motors, engineers also must investigate the capabilities provided by compatible motor controllers. A controller's closed-loop circuit responds to commands from a computer and moves a motor or actuator accordingly. It makes no sense to choose ideal motors only to find their controllers provide few of the operations a test system needs.

Some motor suppliers offer software tools that run on a host PC and download motor-control sequences to a controller box. That type of software works well if you need to move an object in a well-defined repetitive sequence without change. But this type of control may not adapt to situations that change based on test results. Say a product fails an early test, the motion controller should alter its operation and nudge the failed product into a rework bin.

Good interaction between motion-control software and T&M software provides the key to successful integration of test hardware and motors. Motion-control software aimed at programmers usually comes as a set of drivers. Software suppliers often refer to these drivers as an application program interface (API), which defines exactly how the motion-control software receives motion commands and how it reports results, including any error conditions.

A typical API may provide over 100 function calls, such as GetMotorStatus or SetMotorOn. These function calls let software developers set motor characteristics, initiate movements, and monitor operating conditions. Manuals and reference materials explain each function call and may include program examples.

The function calls let programmers integrate motion-control operations into code written with Visual Basic, C, C++, or Delphi (Pascal). Test-software packages such as LabVIEW, TestPoint, or DT Measure Foundry also have access to the motion-control APIs. Many motor-control software packages also include "wizard"—simple programs that display radio buttons, controls, and indicators that let users quickly set up, initialize, and test their motors.

Motor controllers use a variety of feedback devices, including potentiometers and optical encoders—coupled to a motor's shaft—to keep the motor stable and to move it properly under computer command. Engineers often use similar sensors to monitor the location of a moving fixture or actuator. One class of optical sensors, for example, provides two out-of-phase pulse signals produced by an encoder wheel to indicate incremental position changes. Simple circuitry and software equate pulse counts to position.

Safety First

Although engineers can set up testers without safety interlocks, their absence may cost a company dearly in lost time and money. Motion systems that include pressure-sensitive strip switches, light curtains, or other object sensors can help prevent injuries. All systems that include moving parts must include panic switches that let operators immediately kill power to equipment. And openings should have interlocks that prevent operation without the presence of doors and access panels.

Protecting the equipment itself includes switches that will stop mechanisms at or before their travel limits. Many controllers accommodate the connections for such limit switches, but programmers enable the controller to accept switch inputs!

Second, when power fails—and it will—equipment should recover gracefully, and firmware should not simply restart an operation from the point of power loss. Motion controllers may not "remember" their last position or operation, and restarting without knowledge of that condition can damage mechanisms and the product undergoing testing. A graceful recovery should restart operations assuming the worst possible condition. That recovery may require human intervention to reset equipment.