CANopen: Difference between revisions
m Date the maintenance tags using AWB |
→CANbus: Add starting point for common messages, start of criticisms rant. |
||
Line 10: | Line 10: | ||
==CANbus== |
==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]]). |
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]]). |
||
CANopen messages conform to similar CAN limitations of 8 bytes for the data. A couple of useful messages to illicit a response from a CANopen device: |
|||
{| class="wikitable" |
|||
|- |
|||
! CAN ID |
|||
! LENGTH |
|||
! DATA |
|||
! Description |
|||
|- |
|||
| 0x0 |
|||
| 2 |
|||
| 1 0 |
|||
| Put bus into operational mode |
|||
|- |
|||
| 0x80 |
|||
| 0 |
|||
| |
|||
| Send a SYNC message, which triggers devices to send data |
|||
|} |
|||
Terms |
|||
PDO Process Data Object - Inputs and outputs. Could be of type RPM, V, Hz, mAmps etc |
|||
SDO Service Data Object - Configuration things, possibly NODE ID, Baud rate, offset, gain etc. |
|||
COB-ID - CAN Object Identifiers |
|||
EDS - Electronic data sheet. This is an INI style file. |
|||
DCF - Device configuration file. This is modified EDS with with settings for node ID and baud rate. |
|||
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, then attempt to figure out how the specification that to try to digest the specification. |
|||
The EDS file is opaque. |
|||
==References== |
==References== |
Revision as of 02:09, 29 November 2006
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.
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.
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).
CANopen messages conform to similar CAN limitations of 8 bytes for the data. A couple of useful messages to illicit a response from a CANopen device:
CAN ID | LENGTH | DATA | Description |
---|---|---|---|
0x0 | 2 | 1 0 | Put bus into operational mode |
0x80 | 0 | Send a SYNC message, which triggers devices to send data |
Terms PDO Process Data Object - Inputs and outputs. Could be of type RPM, V, Hz, mAmps etc SDO Service Data Object - Configuration things, possibly NODE ID, Baud rate, offset, gain etc. COB-ID - CAN Object Identifiers EDS - Electronic data sheet. This is an INI style file. DCF - Device configuration file. This is modified EDS with with settings for node ID and baud rate.
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, then attempt to figure out how the specification that to try to digest the specification.
The EDS file is opaque.
References
External links
- CANopen overview
- CANopen: An Introduction
- Free Linux-based CANopen source code
- can4linux
- CAN Festival Linux CANopen library