CANopen
From Wikipedia, the free encyclopedia
CANopen is a standard Controller Area Network open protocol for process control systems. The CAN protocol is an ISO standard, ISO 11898, used for serial data communication. The CAN protocol has been on the market since 1986. It is a mature standard, with many products and supporting tools available.
Contents |
[edit] Typical CANopen devices
Typical CANopen devices, such as flowmeters, have a standard 5-pin or 8-pin connector, and interface to control hardware, to allow liquid flow measurement to be conveyed digitally.
This is in contrast to traditional flowmeters that send 4-20mA or 1-5 volt analog output signals proportional to fluid flow.
A typical CANopen device such as the Krohne product, used in the bottling industry, can provide quick (e.g. 1/60 of a second) response to changes in fluid flow.
[edit] CANbus
CANbus uses differential (balanced) two wire connections, where each node has a male 9 pin d-type connector. Encoding is NRZ (Non-return-to-zero).
[edit] CANopen Protocol
CANopen messages conform to similar CAN limitations of 8 bytes for the data. A couple of useful messages to trigger a response from a CANopen device:
| CAN ID | DATA LENGTH | DATA | Description |
|---|---|---|---|
| 0x0 | 2 | 1 0 | Put bus into operational mode |
| 0x80 | 0 | Send a SYNC message, which triggers devices to send data |
[edit] CANopen Terms
PDO Process Data Object - Inputs and outputs. Values of type RPM, V, Hz, mAmps etc.
SDO Service Data Object - Configuration settings, possibly NODE ID, baud rate, offset, gain etc.
COB-ID - CAN Object Identifiers
EDS - Electronic data sheet. This is an INI style formatted file.
DCF - Device configuration file. This is modified EDS with with settings for node ID and baud rate.
The EDS file is a file format, that describes the communication behaviour and the object dictionary entries of a device. Those EDS files are mandatory for passing the CiA CANopen Conformance Test. A free EDS checker is CANchkEDS
[edit] Criticisms
It has been said that CANopen is difficult to understand. It may be easier to work from the bottom up rather than from the top down. I.E., look at the individual messages that go back and forth on the bus with a real device, rather than attempt to digest the specification.
