The Innova automated microbiological specimen processor has 21 motion axes, grouped into five modules. CANopen supports the machine's various motions.

Medical instruments are increasingly sophisticated, which has increased regulatory requirements and compliance testing. In the past, systems tended to use one centralized computer for motion control. This balanced the — at the time — expensive processors against the cost and complexity of wiring and interface boards that were needed to bring all the signals back to the central processor. Unfortunately, it was all-too-easy for electromagnetic noise from a nearby walkie-talkie to grind a whole machine to a halt. Additionally, sharing so many diverse real-time operations on a single processor required much more testing: Whenever any module or functional unit was changed in the system, all of them needed re-validation. There was no isolation between subsystems.

A better approach, called distributed processing, involves placing the computers close to what they are controlling. This minimizes cabling, improves reliability, and reduces cost. Distributed processing also helps isolate the hardware and the software in each of the modules from the rest of the system.

Large systems often group multiple servo axes, along with their embedded processors, into modules. Common groupings would include a sample presentation module (which lets technicians introduce bodily fluids and the like to the instrument in a variety of bar-coded sample containers), a sample transfer and dispensing module, and a consumables-handling module. But how does the central processor control the distributed servo axes with devices such as grippers, small cranes, and pumps so they know when, where, and how fast to move?

The answer comes from a protocol called Controller Area Network (CAN), first implemented by Bosch in the automotive industry for critical applications such as brake-skid control. Here, protocol is defined as a set of rules used by controllers to send data across small networks. CAN allows bus lengths up to 40-m long operating at 1 Megabit/sec. It handles both the physical and data link layers, with automatic error detection and retry, providing a reliable interface between modules without the need for software intervention.

Many processors already include the CAN interface peripheral in the same manner as they include a serial port. Only a transceiver and connector must be added. The basic CAN bus consists of two wires in a twisted pair. Both ends of the bus have terminating resistors to quickly bring the bus to a “passive” state (where both wires are at the same voltage) when none of the devices (such as grippers) connected to the bus are actively transmitting. Each device (or node) is connected to the two wires of the CAN bus, which lets any node send or receive messages.

Above this hardware level, the system still needs a way to agree upon what types of messages are available to it, how messages are formatted, and how to use them to specify, start, stop, and monitor the various motions needed. CANopen has established a set of specifications covering these needs. CANopen is an “open” protocol, meaning it is openly published and manufacturers don’t need a license to use it.

CANopen includes a range of documents from hardware specifications (DS-102), to standard message identification numbers and communications (DS201-207) and standard Objects used to configure CANopen (DS301-302). At the top level are the profiles which define how to communicate and the standard functions included in a conforming drive, as well as how parameters are configured. These profiles include IO Modules (CiA-401), Drives and Motion Controls (CiA 402), and more specific areas such as “medical diagnostic add-on modules: Electrocardiogram” (CiA 425).

A big advantage to CANopen is that any medical manufacturer can use it. This makes it easy to mix and match components from different suppliers. Another advantage is the protocol supports millisecond-level motion timing, so equipment can operate in a real-time, speedy manner, depending on small and well-determined delays. It is the real-time capability of the protocol and its inherent error handling and fault confinement that makes this standard so applicable for medical devices.

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. For example, 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 see what infection a patient is fighting. The Innova speeds along at about 600 samples/hour.
CANopen message standardization

In this controlled network, the two twisted wires between the resistors (R) is “the bus." Each "unit" or node on the network has an identifier under CANopen. Here, they happen to be labeled 1, 2, 3, 4, and 20. (Nothing special, the controlling CPU could have as easily been labeled 5.) Short stubs (wires) connect the bus to each of the nodes.

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.can-cia.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 NMT includes the capability to change node states from that of being configured to that of being active. It also provides for error, time synchronization, and the so-called “heart-beat” messages, which indicate the status of nodes. SDOs are single-node 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, for instance. The node generating data broadcasts it according to the trigger mechanism, and the nodes configured to accept the data consume it.

Under the hood of CAN
The protocol’s real-time capability comes from a combination of 1 Megabit /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 a random amount of time 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 non-destructive collision avoidance mechanism which arbitrates messages from multiple nodes based on the priority that has been pre-assigned 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 high-priority message (such as an error message), while a lower-priority message (such as a switch has opened) is already under way. At a 1 Megabit 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.

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.