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 ]

Lab Instrumentation Requirements vs. CAN Physical Layer Specification

The modules comprising our instrument require several electrical services in addition to CAN communication. We need ±24V power, 50/60Hz line synchronization, hardware reset, and a low-jitter hardware synch signal. We also want to provide separate paths for returning unbalanced supply currents, for establishing system ground reference, and for dumping shield currents. Table 1 shows how we adapted CAN's 9-pin D-sub connector to fill all of these requirements. Note that it is possible to connect a standard 3rd party CAN module into our network by using a cable with wires on only pins 2, 3, 7, and 9. In this case, the 24V supply would only provide power for the galvanically isolated CAN interface of the module. We are not using galvanic isolation of our CAN interfaces, so the ±24V supplies all power requirements in our modules.

The 50/60Hz sync line allows us to make very stable measurements in the presence of substantial line interference. Non-synchronous measurements are prone to exhibit low-frequency beats as their phase slowly slips with respect to the power lines.

The SYNC-H/RS and SYNC-L lines allow us to distribute a very accurate and stable timing signal throughout the system. This differential signal can serve as a clock, sync, or trigger for various modules depending on their requirements. The sub-microsecond latency and jitter available through this SYNC mechanism is far better than we could have obtained through the CAN bus itself. Commands sent over the CAN interface can be used to configure or arm modules so that they can make use of this timing signal as desired.

We will use CAN transceiver chips to control these SYNC lines, so in normal operation they will have the same electrical characteristics as the CAN bus. However, pulling Sync-H/RS to system ground level for a few microseconds will initiate a hardware reset of all modules connected to the bus.

Figure 1: Comparison of pin assignments on D-Sub Connector

Lab Instrumentation Requirements vs. CANopen Specification

As already mentioned, we were selecting a serial bus for internal use in our instrument lines, therefore slavish adherence to an official specification was not required. Nevertheless, we wished to avoid "reinventing the wheel" to as great an extent as possible. Our earlier designs had also suffered from incompletely engineered and under-documented interfaces between the components of our instruments. It was felt that we could reduce such problems by following an official standard that many people had already spent considerable time designing.

Also, we want to maintain the ability to run 3rd party CANopen modules on our instrument's bus. Therefore, any liberties we choose to take with the DS-301 specification must be compatible with this requirement. The converse is not true, however: we do not care that our own instruments do not function correctly in someone else's network or if our instruments fail to pass CIA conformance testing. There is a substantial difference between the "flavor" of a typical CANopen fieldbus system and the bus required for our instruments. These differences are summarized in Figure 2. As one can see, the developers of CANopen were attempting to solve a very different set of problems than we are. Nevertheless, the CANopen application layer comes fairly close to providing our company with the necessary and sufficient services we require.

Our modules are quite application specific and can be pre-configured to perform their assigned functions in our instruments. There is no need to have dynamic assignment of PDO data nor is there even a need to have configurable COB-IDs for the PDOs. In fact it is desirable to have all these parameters "hard-wired" into the firmware so that our modules know everything about each other at power-on. Because of this determinism, no LMT and DBT capabilities are required on our bus.

Figure 2: Differences between typical CANopen System and Lab Instrument bus

[ Background | Requirements | Default Connections | Emergencies | Update ]

© ESAcademy, 2002

www.esacademy.com
info@esacademy.com