Historically, getting a system to perform a suite of operations, whatever their purpose, rested primarily with the hardware, a solution generally both expensive and inflexible. Hardware provided greater speed, while software offered a higher level of flexibility. But I/O speeds at that time limited communication between the two, forcing designers to minimize the amount of data in the stream in each direction. A computer would compute the setups and might implement them by stuffing simple ASCII code down an I/O bus. The system manufacturer would have provided the appropriate operation functions in a library that the control software could call as necessary.
The explosion of computer capability, along with dramatically faster I/O, opened the door to a world where sophisticated (and increasingly human-friendly) software can fully control “chameleon” hardware (hardware that takes on the characteristics of the software). Changes to these systems often require nothing more complicated than adding specific functions or a few lines of code. In the white paper “Software vs. Hardware Motion Control,” control-software developer KINGSTAR presents a cogent argument for adopting software-based solutions.
The author begins by presenting a model for a machine with 8 axes of servo motion control plugged into a standard Windows PC, then examines cost and performance differences for a hardware-based and a software-based solution.
The Hardware-based Approach
The traditional model requires an 8-axis digital-signal-processing (DSP) board plugged into the computer motherboard. This board represents the single largest cost in this solution. The servo motors it controls, however, may reside at considerable distance. This example assumes a longest distance of 15 feet. The amplifiers reside near the DSP I/O at the PC to minimize the length of shielded cable required between them. Sensors called encoders, on the other hand, must reside right at the motors so that they can determine the exact rotational position of the motors at known intervals. Bridging the distance between the encoders and the motors means connecting them with expensive, high-quality cables. This solution requires Hall-effect sensors, which also demand high-quality shielded cable. The example assumed 8 axes, the capacity of a conventional DSP control board. Calling for even a single additional axis would incur the cost of another DSP board and need another slot on the motherboard. Figure 1 shows the architecture and the approximate cost of this approach.
The Software-based Alternative
The software solution takes advantage of the advances in PC technology over the past couple of decades. The power of the PC motherboard, the speed gains (generally greater than 2 GHz), and other advances of the controlling microprocessor (such as multiple cores) have made the DSP boards an unnecessary cost, as well as a drag on the system. Software supplies all of the motion-control logic, while a communication standard such as EtherCAT (Ethernet for Control Automation Technology) handles high-speed bidirectional communication. Unlike the hardware board, EtherCAT doesn’t limit the number of axes in the motion system and allows mounting amplifiers close to the motors. This configuration (Figure 2) also reduces costs by minimizing the need for expensive shielded cables and keeping them as short as possible, using standard CAT5 cables for expansion. In this example, the resulting system costs less than half of the hardware version.
The software-driven system allows easily adapting to the wide and ever-changing range of extenuating circumstances that represent “normal” in many applications. The short shielded cables are also all identical, minimizing errors and reducing spares costs. This solution also allows adding machine vision to monitor system performance. According to Jerry Leitz, Director of Field Engineering at KINGSTAR, a standard quad-core microprocessor PC would allow devoting two cores to Windows, one core to the real time subsystem RTX64 for servo calculations, and one core to the RTX64 for vision tasks.
The source white paper includes a detailed comparison of the performance and cost of the two solutions.
A Real-World Example
Leitz illustrates a software-based operation with a mail-insertion machine used by credit-card companies, communications providers, health-care companies, or anyone else wanting to perform large-scale monthly billing. It employs 80 servos altogether, pulling in paper containing the printed contents from a roll 17 inches wide and 4 feet in diameter, cutting it into pages, collating the pages, folding them, adding advertisements, and inserting the resulting package into an envelope held open for that purpose, sealing the envelope, and sending it on at a rate of 26,000 envelopes per hour – about 7 per second or 138 ms per envelope. The address may show through a window in the envelope or the system may print it after sealing the envelope, along with adverts for products selected specifically for that customer, if requested. This video shows the machine in operation.
As the envelope proceeds down the conveyor, a sensor on the machine output scans the barcode to ensure that it is legible enough for the Post Office sorters to properly direct it. (We assume this envelope is a one-off, rather than the first of many if the machine ran out of ink, for example.) Any illegible code causes the system to open a gate just long enough to remove that envelope from the stream (20 ms) and closing it again (20 ms) quickly enough that the next envelope proceeds normally without slowing the system down. A human operator handles the defective one manually.
Keeping such an elaborate system under tight control requires constant vigilance. In this case, the system reads a sensor called an “encoder” on each motor that establishes its exact position (a) at that moment. The known speed of the motor determines that the motor should be at position (b). The difference between them is the error. The system calculates the change in torque necessary to correct the error.
To keep the system on-track in real time, it generates an interrupt every 500 µs. Certain events occur at that time. First, the system builds a network packet containing the command data for each amplifier based on the information from the previous interrupt. It delivers the command data to each servo in turn, calculating where it should be and the necessary command inputs to get it there, then sends the packet on to the next servo until it has addressed all of them, then sends it back to the PC. As a last step, the system processes any new instructions received from elsewhere. Then it goes to sleep until the next interrupt. Handling this level of complexity proves far simpler if the instructions come from software.