The SilverDust servo controller uses the standard CANopen bus. CAN_H and CAN_L are the two data bus connections. The Ground, V+, and Shield are optional. The device has terminating resistors selected by way of a jumper in the black header on the front of the unit.

A good example of its use comes from the Innova automated microbiological specimen processor from Dynacon Inc. This machine has 21 motion axes, grouped into five modules. The design required that coordination among axes could change, depending on specimen type and laboratory workflows. All modules are controlled by a central unit communicating via CANopen’s application layer. Each of the servo axes also has its own CANopen chip. The system engineer can easily program the application layer to account for modules being added or removed. That’s why relying on CANopen, instead of developing a custom solution, reduces costs, risks, and development time.

In the Innova, CANopen supports various motions. The specimen processor selects a sample tray and an arm moves down to uncap a sample, and, in some cases, dilute it. Coordinated motions include a small crane moving side to side, and the table moving back and forth. A device draws a pattern with the sample material onto a petri dish, covers the dish, and then places everything in a controlled temperature to determine the infection. The Innova operates at about 600 samples/hour.

Under the hood of CAN

The protocol’s real-time capability comes from a combination of 1 MB /sec communications rate, short data packets for sending bits of information (comprising 0s and 1s) through the bus, and the prioritization of the packets by nondestructive bitwise arbitration, which makes sure all the data gets through intact. This method contrasts to that of Ethernet, in which there is no data arbitration. Several devices might all try to “talk” at the same time, in which case they all have to shut up (the data is destroyed) and wait before trying again.

CANopen uses what is called the identifier frame of the data packet for arbitration. Identifier frames comprise either 11 or 29 bits, and up to 8 bytes of data. Identifiers have the dual role of deciding which packet takes priority and of identifying packet contents. To send a packet, a node (in this case, the embedded processor in each servo axis or the master computer) writes the data to the CAN peripheral. The hardware waits until the bus has been quiet (passive state) for a minimum time and then asserts a start-of-frame bit onto the bus. The hardware supports a nondestructive collision avoidance mechanism which arbitrates messages from multiple nodes based on the priority that has been preassigned to each message. The highest priority message is transmitted with no extra time incurred by the arbitration process.

The small packet size of 8 bytes reduces the latency time — how long a device has to wait get the next message in. This minimizes the delay for a highpriority message (such as an error message), while a lower-priority message (such as a switch has opened) is already under way. At a 1 MB data rate, packets take between 47 and 135 microseconds, according to the number of data bytes being sent. Packets are multicast — that is all nodes can receive them simultaneously. Each node on the bus then acts upon the data or discards the packet, according to their function and configuration.

Message standardization

CANopen protocols are available through CAN in Automation (CiA), an international group that develops and supports CANopen and other CAN-based higher-layer protocols (www.cancia.org). In CANopen, the data to be transferred is identified through a 16 bit data dictionary, which includes data sizes and types. The dictionary allows for the identification of networked devices and their properties.

Here, communications are divided into three major classifications: network management (NMT), service data objects (SDO), and process data objects (PDO). NMT includes the capability to change node states from that of being configured to being active. It also provides for error, time synchronization, and the “heart-beat” messages, which indicate the status of nodes. SDOs are singlenode to single-node communications.

PDOs send repetitive data from one node to one or many other nodes. Data exchanges can be triggered by time or by events (changes in the data) and can be synchronized or asynchronous. They are useful for monitoring IO and updating sensor values or motor positions.