Understanding CAN Protocols I
This is the first article in a serie about CANBus and higher-level protocols, which are extensibily used in Industrial environtmens along with Embedded Systems.
CANBus standard describes only the layer 1 and 2, from an OSI point of view, dealing with physical and datalink activities. On the other hand, CANOpen is a protocol which lies in the OSI layer 7.
There is no need for intermediate layers in these kind of busses since all of them belong to the same network segment; neither the notion of session is available in CAN networks.
As can be seen in the image above, CANBus uses two wires for the communication bus and transceiver only need hook these two lines (and the ground). In some representations, as the above, you may see the bus both sides ended, this is usually done by a 120 Ohms resistor which is only mandatory when the bus exceeds a normal length.
For now, the fields, in a CANBus Frame, we are going to care about are identifier, which is 11 bit wide in the base version, and the data field holding as much as 8 bytes in each frame, the rest of the fields deal with synchronization of frames and error checking, you can find them in Wikipedia CAN Entry.
CANOpen
CANOpen is a protocol built on top of CAN, but can run in different link layers, which implements an object centric message system. The main entity in CANOpen is the Object Dictionary, which is a description of all the objects supported by an specific device, it doesn’t matter the format it is delivered in as long as both side of the communication are aware of it. The protocol is profile based defining each of them different objects that must be implemented by the device
Each Object has its own 16bit wide index and another 8bit wide address for referecing subdata fields. As can be seen in the next table there range of these address which are mapped to specific functions described in different profiles e.g. CiA 301 (communication profile area):
In order to simplify communication in CANOpen redefines the CAN identification scheme as follow and renaming it as COB-ID:
So with this new specification we have 4 bits to specify the function the message is requesting to perform and 7 bits spare for device’s ID which span from 1 to 127, being 0 forbidden.
Function Codes can be either pre-defined by the standard or custom, modified after the devices powers-up.
The tables below shows the configuration for the pre-defined connection set; the first for broadcast messages and the second one for peer-to-peer object messages:
Administrative Messages:
Service Data messages (SDO):
- This messages provide access to device’s objects using the Object Dictionary index and subindex and allows data transfer of any length.
- Each message needs to be confirmed and each request / reply transports 8 bytes rendering this kind of service not suitable for RT data transfer.
Process Data Object (PDO):
- Used to transfer RT data from one producer to several consumers and each message is limited up to 8 Bytes.
- Each PDO is described by two objects, one for setting the COB-ID, transmission type, inhibit time and timer period and the other to map list of objects from the Object Dictionary mapped into the PDO.
- The objects mapped to a PDO are configured using SDO messages.
- There are to modes: SYNC (triggered by a SYNC object, ASYNC (triggered by a device event)
- Inhibite time: Minimun time betweet 2 PDOs
- Event Timer: Transmission Trigger
Predefined Messages:
- SYNC: Used to synchronized operations across the network, when device receive a SYNC message the perform the expected action.
- Time — Stamp: Common time frame reference
- Emergency: Triggered by an error in a device
- Node/Life Guarding: Monitor state of Devices, detects network errors, etc
- Boot-up: By sending an NMT message the slave change from state Initialising to Preoperational
Originally published at http://www.gabrielgonzalezgarcia.com on June 21, 2011.
