Can do

Distributed, multiaxis motion-control systems need to make optimal use of bandwidth in the digital interface between host controller and servodrive. This means using an interface with a high data/total packet size ratio. One approach is to generate both trajectories and position updates in a central motion controller. The controller then sends digital torque or velocity commands to a digital servodrive via a high-speed interface. Examples of high-speed interfaces are Sercos which runs between 2 and 16 Mbits/sec, 100BaseT Ethernet at 100 Mbits/sec, and FireWire, or IEEE1394, at 400 Mbits/sec.

The servodrive updates the controller with the motor shaft position for proper commutation via the serial interface, replacing the conventional +/-10V encoder interface. In a distributed system, the encoder is connected to the drive locally, not to the host controller. The motor shaft information is used by the drive for commutation. But because the position loop is closed in the controller, it is also sent to the controller via the interface for position feedback.

The drawback to this approach is that the serial interface between the controller and the drive needs to have high bandwidth: the higher, the better. This keeps latencies as small as possible. But it also adds cost and complexity to both drive and controller because a higher bandwidth interface is more expensive.

Also, the drive's resources are not being used optimally. Digital servodrives employ a microcontroller or DSP. If this microcontroller only performs torque control (updating the current loop and commutation), it will be idle much of the time. In addition, a dedicated controller is needed in the host controller to close the position loop and perform all the trajectory generation and also send out the torque commands over the high-speed interface.

An alternative approach closes the position loop in the digital drive. The host controller sends position commands to the drive. Closing the position loop in the drive reduces the position update rate from the host to 100 msec or less. A relatively low-speed serial link such as a CAN interface can handle these commands. The CAN data packet structure also lends itself to sending position setpoints that contain position, velocity, and time in a single frame.

To further reduce the position command update rate, the drive can interpolate trajectories between positions. This interpolation lets the host controller split the overall motion trajectory in segments. The drive just gets the position of segment end points.

In a system with linear interpolation, the position command would contain position and time. This lets the drive generate a straight-line interpolation. A linear curve (x(t) = at +b) requires coefficients a and b. The position information p_n and p_n+1 at t_n and t_n+1 allows determination of a and b for the segment between t_n and t_n+1.

In drives able to perform third-order interpolation, the position command contains position, velocity, and time. A third-order curve (x(t) = at³ + bt² + ct + d) requires coefficients a, b, c, and d. The position information p_n and p_n+1, velocity information v_n and v_n+1 at t_n and t_n+1 allow determination of a, b, c, and d for the segment between t_n and t_n+1.

The above approach can be implemented via the CAN Open communication protocol. The maximum bit rate of CAN is 1 Mbit/sec, with message frames containing up to 8 bytes of data. The 8 data bytes of a position command message are assigned as follows: 3 bytes for segment end-point position, 3 bytes for segment end-point velocity, 1 byte for segment time (1 to 255 msec), and 1 byte for an integrity counter which ensures that consecutive segments are processed in the proper sequence.

The end point of one segment is the start of the next. So calculation routines need only the location of segment end points. It's always assumed that the first segment starts at present position and zero velocity. The drive can perform a third-order interpolation knowing position and velocity of both segment start and end points (to determine the four coefficients of a cubic curve, four equations are necessary). The segment time can vary, which improves accuracy in case of rapid position changes. Reducing segment time makes the inaccuracy introduced by a third-order interpolation smaller.

Segment time selection is based on the number of axes, CAN-bus bit rate, and data throughput requirements. The shorter the segment time, the more position-velocity-time commands the CAN bus can accommodate per axis. So if more axes are needed, for a given CAN-bus speed, the segment time needs to be increased. This also depends on other CAN messages and bus traffic.

For example, at 1 Mbits/sec, an 8-data-byte message takes worst-case about 130 sec to transmit (130 bits total message length comprised of 64 data bits plus overhead). If four axes require synchronization, then it takes about 4 130 = 520 sec to send a position command to each of them. There must be enough network time for messages for status and emergency. Since the drive performs cubic interpolation, position update rates are only on the order of 10 to 200 msec, depending on the application. The relatively slow CAN bus easily accommodates such rates and provides enough bandwidth for other messages.

It's also critical that multiple drives stay synchronized. The CAN-bus time stamp message, broadcast regularly, maintains this timing. The time stamp message basically corrects for internal clock differences between servodrives. How often it is sent depends somewhat on the application. Because oscillator clocks typically don't drift much, a typical range is every 5 to 60 sec.

This approach effectively decouples the trajectory generation from servoloop closure. Hence those two functions need not synchronize tightly. But the time basis for each axis must be in sync. A 15-level FIFO buffer in the drive can loosen up timing requirements with the host. The host can control the buffer pointer via the CAN interface. The drive pulls the first available position command dynamically from the buffer, making it unnecessary to preload the complete motion profile.

This approach has several advantages over centralized position control and trajectory generation. First is the idea of "soft motion" whereby the motion trajectory is generated in the PC or controller CPU. It needs no dedicated motion control hardware, except the network card for the CAN bus. The axis count can be changed easily without adding hardware on the host controller. Secondly, a lower bandwidth interface can be used, reducing cost and complexity.

The CAN bus can also handle other devices such as I/O modules and sensors. And the digital interface between drive and controller provides extended diagnostics information. This lets the operator read internal drive status, bus voltage, motor currents, errors, and temperature, among other parameters.

Traditional servosystems close the position loop in the controller and communicate with the drive through a high-speed interface such as Sercos or fast Ethernet. An alternative approach shifts the position loop and higher order trajectory generation to the drive, employing the drive's unused processing power. This allows the use of a slower interface such as CAN.

In this new implementation, the drive performs the more intensive third-order interpolation. The PC-based controller handles the linear interpolation.

Jan Bosteels, Product Manager
Advanced Motion Controls
Camarillo, Calif.