Jump to content

CANopen: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
SmackBot (talk | contribs)
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