Frequency response plots that pinpoint problems
Manager Motion Engineering, Inc.
Santa Barbara, Calif.
Closed-loop control systems are sometimes shipped from the factory with resonances and other operational difficulties that aren't supposed to be part of the package and are not well understood. Frequency-response plots (also called Bode plots) can identify such problems which may be hard to find by other means.
Consider, for example, the frequency response of a simple brush motor with an inertia wheel attached to its shaft.
Standard PID tuning results in audible " growling" before the system reaches satisfactory performance. A quick frequency response test shows a resonant peak at 685 Hz. This happens with no motor coupling or similar normal sources of mechanical resonance. The mechanical resonance comes from the mass resonating with the motor-shaft deflection. Filtering this peak out allows a 6X increase in control-loop gain with the same amount of audible noise, control stability, and better disturbance rejection.
Of course, engineers have used frequency response tests to debug mechanical systems for decades. But new capabilities make it possible to carry out such examinations remotely, over networks. It is not possible to conduct a sweep over just any network, however. A network that supports this sort of real-time testing must handle communications while keeping signal latency to less than 25 sec. Otherwise, random delays in signal transmission over the network will garble the results. This eliminates the possibility of using wellknown networks such as ordinary Ethernet, CAN, FireWire, and Sercos.
A network called SynqNet, however, can provide the necessary response to make possible frequency response sweeps conducted over a network. There are several aspects of network operation that contribute to the realtime response. But a few of the most important factors include measures gauged at keeping down skew and jitter, and minimizing the network overhead to handle transmission protocols.
For example, SynqNet limits jitter (beating caused by clocks at master and slave nodes running at slightly different frequencies) to less than 1 sec through use of phase-lock loop techniques. These effectively synchronize independent clocks of each network slave to the network master. In contrast, networks such as TCP/IP and IP/UDP-based Ethernet networks can cut jitter to 20 sec at best through use of time stamps.
One of the areas that has historically been an inconvenience when taking frequency-response data on a motion-control system is the process of getting excitation data off the system and into the analysis package. Often this requires bringing in a spectrum analyzer and hacking up the wiring harness to access the appropriate signals. In addition, an excitation signal needs to be cleanly inserted into the system. After all this is set up, the data needs to be recorded, scaled, and analyzed. While no individual step here is that difficult, it can take hours or days to get a good frequency response from a system the first time.
Considering this situation, what could we do to improve it and make frequency response measurements simpler, faster, and easier? Having all the data available in the controller eliminates the need for wiring harness modification. Adding a system-excitation feature in the controller makes it much more convenient to excite the system. Using a high-bandwidth data pipe to get the excitation off the controller and to the PC lets the processor in the PC quickly handle sophisticated signal analysis.
Use of an all-digital network eliminates unnecessary digital/analog and analog/digital conversions, minimizing noise and delays in the data. Adding in a native TCP/IP layer to the software lets this take place on any machine in the Ethernet network environment, even if the test runs from your laptop. And it is a straightforward matter to construct a simple graphical interface that lets you concentrate on the results, not on setting up the test. It can be a simple process to send data to Matlab or your favorite postprocessor.
Of course, designers would want the tool to natively understand the control loop on the controller. This would let it show controller frequency responses and simulate changes to the control algorithm without retesting. It is easy to see that no one step allows such an improvement over old measurement methods. It is the combination of many advances in networked controllers and improved software architecture that ends up being greater than the sum of the parts.
Such procedures enable sending commands over the network to sinesweep an axis, or even two axes, across a range of frequencies. The resulting feedback is passed back over the network and recorded. Two-axis tests take place with correlated excitation with the response of both axes tested simultaneously. The data is used to compensate for mechanical anomalies by adjusting gains in the control feedback loop.
The technique can help automate frequency response tests on the production line. This takes place by inputting Bode parameters as a command line, then storing the resulting data.
When a machine has an unexpected resonance as, for example, from loose bolts, the anomalies will show up on the frequency response. Comparing the data to a known good frequency response will highlight the problem and provide hard data for the engineering department if it needs to get involved.
Also, when a machine has a puzzling servo problem in the field, the field technician can run a frequency-response test and send it back for comparison to the original data taken on the production line. Significant changes in frequency response in the field give clues to the source of the problem.
Fortunately, special-purpose diagnostic software is now available so that it is not necessary to have expensive auxiliary equipment to obtain frequency-response data. An example is the controls Toolkit, offered by Motion Engineering, which operates over standard SynqNet networks.
Motion Engineering Inc.,
(805) 681-3300, www.motioneng.com