Basic CAN Recap
The basic CAN was originally created for automobiles. It is possible to save a lot of wiring by using a simple “multidrop” bus instead of separate “star”-wiring to all sensors and actuators. Each car is a closed CAN network (or rather: several). Thus the car-maker can decide freely how the IDs are chosen and data in messages are formatted. This is typically described in a DBC-file – specific for the make and type.
Facts about the basic CAN
- ISO11898 OSI-stack level 1+2 – Physical & DataLink Layer
- Typically 2-3 wires (differential + common ground) – e.g. RS-485 – 4 wires with power
- Typically Linear network with 120 Ohm termination at both ends (at 1 Mbps)
- Max 1 Mbps up to 40m, half the speed when doubling the length etc.
- Data Frame is 44-108 bits + bitstuffing for synch
- Message ID in 11 (CAN 2.0A) or 29 bit (CAN 2.0B)
- Data: 0-8 Bytes per message (fixed usage per ID on a given system by designer)
- CRC 15 bits (Hamming Distance is 6) – Ethernet has 31
- Bus Arbitration: CSMA/CD with a twist:
Most consecutive zeros win (low ID). This means that two CAN devices can start transmitting simultaneously, and the one with the lowest ID will win and continue to transmit a legal message, while the other one silently “backs off”.
Comparing CAN with Ethernet
- Ethernet may take advantage of existing installations (cables, switches)
- Ethernet simply throws away erroneous frames – needs TCP (or user) to retransmit end-to-end
- CAN requires ALL nodes to ACK during transmission!
(but ”parks” a faulty node) - CAN supports priorities by Message ID (lowest ID wins)
- CAN’s shorter messages means shorter waiting time (for a given transmission rate)
- CAN has HW Error-Detection and retransmit on Layer 2
- Missing ACK, Collision, Bus Off
CANOpen
CANOpen is an extension of CAN for the factory floor. The designers realized that CAN is not only cheap, but also very robust in noisy surroundings – like a factory floor. A factory network consists of components from many vendors. For this reason a higher level of standardization than what is offered by CAN was needed.
Facts about CANOpen
- OSI-Stack levels 3-7 (Somewhat simplified)
- Standardizes
- A number of messages and datatypes as well as byte-ordering etc.
- Fragmentation to allow longer messages than the usual max 8 bytes
- Addressing and Token management for shared resources
- Network Management
- Concepts like Events on changes
- Simple mapping of any input to any output
- Overall Concept: Producers & Subscribers
- Introduces an ”Object Directory” – a table of parameters
- Heartbeat – All nodes broadcast their status at given
intervals. (Somewhat like the ”Beacon” in WiFi) - ”Open” because:
- May run on same network as ordinary CAN (if you avoid reuse of CAN Msg ID’s)
- Can be used by anyone
- May be extended as you please
CANOpen Coding of the Message ID
- Using the 11-bit CAN Msg ID in CiA DS301
- 7 Bits for Node ID 1-127 (0 in ”Broadcasts”)
- 4 Bit for Function Code
- Control Bits Not Recommended for use
- No Polling (RTR)
- No 29 Bit CAN Messages (IDE)
- An implementation may e.g. sacrifice some Node ID’s to get more PDO’s
CANOpen Object Directory
- All setups and process values (data) are kept in a 16-bit indexed table – the Object Directory
- Each Index has up to 256 sub-indices (if more than 1, the first is the number): [Index, SubIndex]
- Example: A manufacturer implements a Real-Time-Clock at index 2000H
- [2000H, 0H]: 3 (The number of entries)
- [2000H, 1H]: Hours (UNSIGNED16)
- [2000H, 2H]: Minutes (UNSIGNED8)
- [2000H, 3H]: Seconds (UNSIGNED8)
- EDS – Electronic Data Sheet – ”ini-file” format or xml
- Applies to multiple nodes – describing the system
- Used by many tools: Analyzers, Configuration, Standard Test etc
- Puts name on Objects = Easier in tools – does not go into OD
- DCF – Device Configuration File
- Almost same format as EDS
- Applies to a single node
- Essentially allows store/restore the configuration of a device
- Includes Data for the Object Directory, as well as min/max/default values
- Tools use SDOs to communicate with the nodes to maintain the above
Transmit and Receive Process Data Objects
- TPDO = Transmit Process Data Object.
- RPDO = Receive Process Data Object.
- Transmit and Receive direction is related to the CAN-bus – Example:
- Process Data from a thermo-coupler in the Process Environment is read via the node’s A/D and written into the Object Directory – and then transmitted on the CAN-bus as a TPDO – possibly with other data as we have up to 8 bytes in this basic CAN message
- All nodes receive this and may update their Object Directory (actuator, Display, LED) if an RPDO has a matching COB ID
- This is PDO linking
CANOpen Message Types
- Network Management (If system has a master)
The first thing to come on line after power-up manages the CAN-nodes. We have the following states:- Bootup
- Pre-Operational (configuration)
- Operational
- Stopped (by error or operator)
- SDO – Service Data Objects
Reads & Writes the parameters in the Object Directionary on other nodes
Typically this is done at startup in Configuration Mode.
It may be done once by an external PC with a CAN-interface – or dynamically by a master
Fragmentation Supported here – Messages build on several CAN packages - PDO – Process Data Object
”Shortcuts” to parameters in the nodes- TPDO for Transmit. Describes what data to measure from input-terminals and transmit on bus
- RPDO for Receive. Describes what data to receive from the bus and output on terminals
- Emergency Objects – used from nodes to the master in case of problems
CANOpen variants
- The ”standard” CANOpen is standardized by CiA
”CAN in Automation”
as DS301 – see others 🡪 - In principle DS301 does not support ”slaves” without a master going operational
– but nevertheless this is often supported anyway - MicroCANOpen is a minimal derivate which as a default has no master. Free Source.
- You can make your own…