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 then 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 alltoo- 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. That is, whenever any module or functional unit was changed in the system, all of them needed revalidation.

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 realtime, speedy manner, depending on small and welldetermined 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.