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 ]
Enhancing the Role of the CANopen Emergency Object
Specification DS301 appears to leave quite a bit of flexibility in the use of the Emergency Object for device-specific purposes. There are several blocks of Error Codes that have been provided to facilitate this: F0xxh is for "Additional Functions", FFxxh is covers "Device Specific" errors, 50xxh covers "Device Hardware" errors, and the entire "6xxxh" block is available for Device Software errors.
We are extending the definition of "emergency" to include any significant events or state changes that might occur in a module, but whose actual occurrence would not otherwise be known without performing continuous polling of the module. Having to do such polling is a substantial programming burden and adds unnecessarily to the loading on the CAN bus. Also, such polling cannot be done by another node on the network unless it has Client SDO capability: a service not supported by some commercial CANopen slave stacks.
We propose to use the block of codes from F000h to FFFFh indicate that there has been a change-of-state in one of the modules subsystems. One bit (of the available 12) is assigned to each subsystem that can have externally significant state information. Whenever there is an event or state change in one of the module's subsystems, the corresponding bit-flag in the Error Code is set. We provide an entry in the Object Dictionary for the purpose of clearing the flag-bits of this Error Code: the "Event Reset Register". Setting a bit of this object clears the corresponding flag of the Error Code. According to the Emergency Object specification described in DS301, the EMCY telegram is sent when (and only when) the Error Code changes. Thus clearing any bits in the Error Code will cause the EMCY telegram to be sent again. But rather than sending an Error Code of 0x0000 upon resetting one of these bits (as mentioned in the standard), we propose to send the new Fxxxh pattern. Clearing a bit in the Fxxxh group indicates that the module has been re-armed to send an EMCY telegram when another state change occurs on that subsystem. Otherwise no further state changes will be announced. We will institute a suitable EMCY 'holdoff time" in order to avoid consuming excessive bandwidth through this module-state reporting scheme.
The five (5) bytes of the "Manufacturer Specific Error Field" provide a set of status flags and mode bit-fields. Up to 40 bits of state/mode information can be communicated with this scheme.
There has been considerable discussion about "borrowing" the official CANopen emergency protocol for the posting of state-change information. The alternative would be to implement the above scheme using PDOs. We have selected to use the emergency protocol for several reasons: it gives these messages a higher priority than all normal PDOs, it allows state information to be presented by a module even when that module is in the Pre-operational or Stopped mode, and it conserves COB-IDs. In the case of our particular CANopen master API, emergency messages have their own dedicated queue and callback function. This should make them somewhat less likely to become lost.
[ Background | Requirements | Default Connections | Emergencies | Update ]
© ESAcademy, 2002
All materials
provided 'as is'
see Disclaimer