Customizing CANopen for Use in an Automated Laboratory Instrument
by M. B. Simmonds, Quantum Design Inc. and
Olaf Pfeiffer, Embedded Systems Academy
This paper was written for and presented at the 8th international CAN Conference in Las Vegas in 2002
[ Background | Requirements | Default Connections | Emergencies | Update ]
Background
Our products are relatively complex cryogenic instruments used by physicists and chemists to perform research in material science. These instruments contain several GPIB (IEEE-488) modules that are controlled by the operator from an application running on a PC. The GPIB was chosen primarily because it was widely used by the scientific/engineering community at that time and enjoyed substantial hardware and software support. It also enabled users to integrate their own 3rd-party instruments into the measurement system.
As we begin looking toward a more modular and modern architectures for our products, however, the shortcomings of the GPIB are becoming more evident. The cost, complexity, and cable size for this 8-bit parallel bus becomes very unattractive when we contemplate using it with a larger number of modules. Even the stacked 26-pin ribbon connectors become a major size problem.
Furthermore, the protocols for required for exchanging short packets with an array of modules is very time-consuming and negates all the advantages one would expect from a parallel bus: we see an effective bit-rate for actual data of only about 200Kb in our systems.
For these reasons, we began searching for an alternative among the various serial busses that have become popular since our original decision was made almost two decades ago. We looked carefully at physical layers based on RS485, FireWire, EtherNet, USB, and CAN. We chose CAN because of several perceived benefits: non-critical cables and connector impedance requirements, good hardware support at the chip level, excellent bus arbitration and error checking, and adequate bandwidth. While we were initially impressed by the promise of very high bit-rates available in other busses, a closer evaluation showed that for our system we would be better off with the shorter frames and inherent collision-avoidance provided by CAN. Also, the high bit rates of these busses would limit our cable lengths or turn impedance matching into a serious design concern.
Having chosen CAN for the lower-level protocols, we needed to select (or invent) an "application layer" for our system. Several options were available, all based upon CAN: DeviceNet, CAN Kingdom, SDS, and CANopen. Here the decision became more a matter of taste since all of these approaches appeared to offer a reasonable set of features. The most important service we required (and did not want to re-invent) was a confirmed exchange of messages longer than 8 bytes: a Service Data Object in the terminology of CANopen. DeviceNet and CANopen appeared to be the most widely used and best supported of these options, with DeviceNet enjoying a much greater presence in the United States. But since it has never been our intention to market fieldbus devices for use except as internal components in our laboratory instruments, this bias toward DeviceNet was not a particular concern for us. This higher baud rate and more efficient block transfers offered by CANopen were of greater importance.
[ Background | Requirements | Default Connections | Emergencies | Update ]
© ESAcademy, 2002
All materials
provided 'as is'
see Disclaimer