120 lines
4.8 KiB
ReStructuredText
120 lines
4.8 KiB
ReStructuredText
|
CANopen Basics
|
|||
|
|
==============
|
|||
|
|
|
|||
|
|
Communication Objects
|
|||
|
|
---------------------
|
|||
|
|
|
|||
|
|
A CANopen network consists of "masters" and "slaves", masters are clients,
|
|||
|
|
slaves are servers. At most one master may be active at a time.
|
|||
|
|
|
|||
|
|
CANopen supports addressing of up to 127 slaves on a bus using node IDs 1-127.
|
|||
|
|
Node address 0 is used for broadcasts to all nodes. Node addressing is simply
|
|||
|
|
mapped onto CAN IDs by adding the node id to a base ID.
|
|||
|
|
|
|||
|
|
The CANopen protocol mainly consists of…
|
|||
|
|
|
|||
|
|
- PDO (process data objects)
|
|||
|
|
- SDO (service data objects)
|
|||
|
|
- NMT (network management)
|
|||
|
|
- SYNC (synchronisation)
|
|||
|
|
- EMCY (emergency events)
|
|||
|
|
|
|||
|
|
**PDO** are regular, normally periodical, status update frames, for example sensor
|
|||
|
|
data. You can log them using the CAN monitor (``can log start monitor …``).
|
|||
|
|
PDOs can be sent at any CAN ID except those reserved for other CANopen services.
|
|||
|
|
|
|||
|
|
**SDO** are memory registers of nodes that can be read and written by masters on
|
|||
|
|
request. SDO requests are normally sent at ID 0x600 + nodeid, responses at ID
|
|||
|
|
0x580 + nodeid. SDOs are addressed by a 16 bit index + 8 bit subindex. Registers
|
|||
|
|
and data types for a given device are documented by the device specific object
|
|||
|
|
dictionary, normally represented as an EDS (electronic data sheet) file.
|
|||
|
|
|
|||
|
|
**NMT** are short datagrams to control node startup / shutdown. There's a special
|
|||
|
|
node state "pre-operational" allowing access to all operation and communication
|
|||
|
|
parameters of a node in a standardized way. NMT requests are sent at ID 0x000,
|
|||
|
|
responses and unsolicited updates (aka heartbeats) are sent at ID 0x700 +
|
|||
|
|
nodeid with length 1.
|
|||
|
|
|
|||
|
|
**SYNC** messages are datagrams of length 0, normally sent at ID 0x080.
|
|||
|
|
|
|||
|
|
**EMCY** messages are sent if a node encounters some kind of alert or warning
|
|||
|
|
condition, they are normally sent at ID 0x080 + nodeid with a length of 8 bytes.
|
|||
|
|
|
|||
|
|
================ =========================
|
|||
|
|
CAN IDs Communication objects
|
|||
|
|
================ =========================
|
|||
|
|
0x000 NMT requests
|
|||
|
|
0x080 SYNC
|
|||
|
|
0x081 - 0x0FF EMCY
|
|||
|
|
0x581 - 0x5FF SDO responses
|
|||
|
|
0x601 - 0x67F SDO requests
|
|||
|
|
0x701 - 0x77F NMT responses / heartbeats
|
|||
|
|
================ =========================
|
|||
|
|
|
|||
|
|
So if any of these IDs look familiar to you, chances are you've got a CANopen
|
|||
|
|
network.
|
|||
|
|
|
|||
|
|
.. note:: CANopen coexists nicely with OBD-II and often does in a vehicle (i.e.
|
|||
|
|
Renault Twizy). OBD-II devices normally are addressed at IDs > 0x780 so are
|
|||
|
|
outside the CANopen ID range. Even if they use non-standard IDs, the devices
|
|||
|
|
normally will detect and ignore frames not matching their protocol.
|
|||
|
|
|
|||
|
|
|
|||
|
|
SDO Addresses
|
|||
|
|
-------------
|
|||
|
|
|
|||
|
|
The SDO address space layout is standardized:
|
|||
|
|
|
|||
|
|
=========== ===============================================
|
|||
|
|
Index (hex) Object
|
|||
|
|
=========== ===============================================
|
|||
|
|
0000 not used
|
|||
|
|
0001-001F Static Data Types
|
|||
|
|
0020-003F Complex Data Types
|
|||
|
|
0040-005F Manufacturer Specific Complex Data Types
|
|||
|
|
0060-007F Device Profile Specific Static Data Types
|
|||
|
|
0080-009F Device Profile Specific Complex Data Types
|
|||
|
|
00A0-0FFF Reserved for further use
|
|||
|
|
1000-1FFF Communication Profile Area
|
|||
|
|
2000-5FFF Manufacturer Specific Profile Area
|
|||
|
|
6000-9FFF Standardised Device Profile Area
|
|||
|
|
A000-BFFF Standardised Interface Profile Area
|
|||
|
|
C000-FFFF Reserved for further use
|
|||
|
|
=========== ===============================================
|
|||
|
|
|
|||
|
|
See `CiA DS301`_ for details on standard SDOs.
|
|||
|
|
|
|||
|
|
For example, a device shall tell about the PDOs it transmits or listens to,
|
|||
|
|
their IDs, update frequency and content structure at SDO registers 1400-1BFF.
|
|||
|
|
This is mandatory in theory but real devices may not fully comply to that rule.
|
|||
|
|
|
|||
|
|
CANopen compliant standard device types like motor controllers need to
|
|||
|
|
implement some standard profile registers. See `CiA DS401`_ for the generic I/O
|
|||
|
|
device class definition and `CiA DS402`_ for motor controllers.
|
|||
|
|
|
|||
|
|
Most devices will require some kind of login before allowing you to change
|
|||
|
|
operational parameters. This is also done using SDO writes, but there is no
|
|||
|
|
standard for this, so you'll need to dig into the device documentation.
|
|||
|
|
|
|||
|
|
Of course there's a lot more on CANopen, but this should get you going.
|
|||
|
|
|
|||
|
|
|
|||
|
|
CAN in Automation
|
|||
|
|
-----------------
|
|||
|
|
|
|||
|
|
More info on the standard and specific device profiles can be found on the
|
|||
|
|
CiA website:
|
|||
|
|
|
|||
|
|
https://www.can-cia.org/
|
|||
|
|
|
|||
|
|
CAN in Automation (CiA) is the international users’ and manufacturers’ group
|
|||
|
|
for the CAN network (Controller Area Network), internationally standardized
|
|||
|
|
in the ISO 11898 series. The nonprofit association was established in 1992.
|
|||
|
|
The aim is to provide an unbiased platform for future developments of the
|
|||
|
|
CAN protocol and to promote the image of the CAN technology.
|
|||
|
|
|
|||
|
|
|
|||
|
|
.. _`CiA DS301`: https://www.can-cia.org/standardization/specifications/
|
|||
|
|
.. _`CiA DS401`: https://www.can-cia.org/standardization/specifications/
|
|||
|
|
.. _`CiA DS402`: https://www.can-cia.org/standardization/specifications/
|