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 ]

Optimizing the Default Connection Set

Since we are adopting a fully static configuration of PDOs, the "default connection set" for our network must provide maximum capability and make it possible for modules to send as much process data as they may need to. The CANopen specification only allows for 4 TxPDOs and 4 RxPDOs per node, a number that we felt was insufficient for our system requirements. On the other hand, the number of nodes permitted by the CANopen specification was far in excess of what would be needed for our instruments.

We have therefore decided to make a tradeoff: limit the nodes to 31 in order to expand the number of default TxPDOs available on each node. Since our modules will serve primarily to control the instrument and report back process data, it is the TxPDOs, as opposed to the RxPDOs that are in short supply. We have therefore devised a strategy for "stealing" COB-IDs of the default PDOs we are excluding from our instrument network (32-127).

Figure 3: Comparison of standard CANopen and QD-CANopen

The technique is to allow each node in the range 1-31 to have three additional images in the range of 32-127. Thus, node #1 also inherits the default PDOs for nodes #33, #65, and #97. The COB-IDs for both RxPDOs and TxPDOs in this range are taken for use as TxPDOs for our modules. We also have available to us the COB-IDs of the default SDOs for these unused nodes. We thus have a total of 34 separate Process Data Objects available on each module for reporting data back to the user's computer. Note that we have retained the four (4) RxPDOs provided by the CANopen standard as part of our own default connection set. The order for assigning COB-IDs to these 34 PDOs is shown in Figure 3, and was chosen so that they would be used in order of decreasing priority.

Since we are not allowing the COB-IDs to be changed, the values listed in Figure 3 can be relied upon: the control computer and the other nodes automatically know a PDO's source node and number from its COB-ID. And since dynamic data mapping is not allowed in our network, the type and meaning of the data payload is also immediately known throughout the network.

Although we are not allowing the COB-IDs to be changed, we do allow bit #31 in the dictionary entry for PDO communication parameter/COB-ID to be set or cleared. According to DS-301, setting of this bit invalidates the PDO and may prove useful in managing bus bandwidth with so many default TxPDOs potentially defined.

Figure 4 summarizes the differences we have described so far between the CANopen standard and our own adaptation of it.

Figure 4: QD Connection Set TxPDOs on node N (0 < N < 32)

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

© ESAcademy, 2002

www.esacademy.com
info@esacademy.com