199 lines
7.7 KiB
Text
199 lines
7.7 KiB
Text
================================================================================
|
|
How to detect and identify CANopen nodes
|
|
================================================================================
|
|
|
|
So you've got a CAN bus with some devices, but you don't know which of them
|
|
speaks "CANopen", if any? The OVMS v3 will help you to detect them and open
|
|
their CANs ;)
|
|
|
|
|
|
CANopen basics
|
|
--------------
|
|
|
|
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.
|
|
|
|
The CANopen protocol mainly consists of…
|
|
|
|
- PDOs (process data objects)
|
|
- SDOs (service data objects)
|
|
- NMT (network management)
|
|
- SYNC (synchronisation)
|
|
- EMCY (emergency events)
|
|
|
|
PDOs are regular, normally periodical, status update frames, for example sensor
|
|
data. You can log them using "can … trace on". PDOs can be sent at any CAN ID
|
|
except those reserved for other CANopen services.
|
|
|
|
SDOs 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.
|
|
|
|
NMTs 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 only 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.
|
|
|
|
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.
|
|
|
|
But of course there may be non-CANopen devices on the bus producing regular data
|
|
frames at CANopen response IDs and/or reading and possibly misinterpreting
|
|
CANopen requests sent to node IDs not planned by the manufacturer. Chances are
|
|
low this triggers problems, but you should be ready to switch off the vehicle
|
|
when doing a scan -- just in case.
|
|
|
|
|
|
Before you begin
|
|
----------------
|
|
|
|
…you need to activate the CAN bus(es) you're going to use. As a CANopen master
|
|
needs to write to the network, you need to start the interfaces in active mode,
|
|
i.e. …
|
|
|
|
OVMS > can can1 start active 500000
|
|
OVMS > can can2 start active 125000
|
|
|
|
… and then start the CANopen master for the bus(es), i.e.:
|
|
|
|
OVMS > copen can1 start
|
|
OVMS > copen can2 start
|
|
|
|
|
|
Detecting CANopen nodes
|
|
-----------------------
|
|
|
|
The "open" in "CANopen" means any implementation can decide how much of the
|
|
standard it implements. There are some few mandatory features though, a CANopen
|
|
slave has to implement, if it wants to comply with the standard.
|
|
|
|
The mandatory features helping to detect and identify CANopen nodes on a CAN
|
|
bus are:
|
|
|
|
- NMT (network management), especially RESET and PREOP
|
|
- NMT bootup event messages
|
|
- Standard SDO access in pre-operational mode
|
|
|
|
If you've got CANopen nodes on a bus, even silent ones, issuing "copen … nmt
|
|
reset" will tell all of them to reboot, and as bootup messages are mandatory,
|
|
you will see them in the OVMS log output like this:
|
|
|
|
I (162904) canopen: can1 node 1 new state: Booting
|
|
|
|
The OVMS CANopen master continously monitors the network for NMT and EMCY
|
|
messages. After bootup of all nodes, you can get a list of all nodes that have
|
|
been detected by issuing "metrics list co.":
|
|
|
|
OVMS > metrics list co.
|
|
co.can1.nd1.emcy.code
|
|
co.can1.nd1.emcy.type
|
|
co.can1.nd1.state Operational
|
|
|
|
Note: if you request a reset, nodes may decide to boot into pre-operational
|
|
state. That may produce some error messages. Don't worry, you can resolve this
|
|
anytime by issuing "copen … nmt start".
|
|
|
|
|
|
Identifying CANopen nodes
|
|
-------------------------
|
|
|
|
In pre-operational state, a CANopen node must be accessible at the CANopen
|
|
default IDs. That means if the node supports SDO access, we can query some
|
|
standard attributes from it.
|
|
|
|
That's what "copen … info" and "copen … scan" do. "copen … scan" queries all 127 node
|
|
IDs for the SDO standard device attributes. A complete scan takes about 20
|
|
seconds. A typical scan could look like this:
|
|
|
|
OVMS > level debug canopen
|
|
OVMS > copen can1 scan
|
|
Scan #1-127...
|
|
Node #1:
|
|
Device type: 0x00000000
|
|
Error state: 0x00
|
|
Vendor ID: 0x0000001e
|
|
Product: 0x0712302d
|
|
Revision: 0x00010019
|
|
S/N: 0x47c5…………
|
|
Device name: Gen4 (Renault Twizy)11 November 2011 12
|
|
HW version: 0x00000003
|
|
SW version: 0712.0001
|
|
Node #23: SDO access failed
|
|
Node #25: SDO access failed
|
|
Node #27: SDO access failed
|
|
Node #30: SDO access failed
|
|
Node #87: SDO access failed
|
|
Done.
|
|
D (227994) canopen: ReadSDO #23 0x1000.00: InitUpload failed, CANopen error code 0xffffffff
|
|
D (228194) canopen: ReadSDO #25 0x1000.00: InitUpload failed, CANopen error code 0xffffffff
|
|
D (228444) canopen: ReadSDO #27 0x1000.00: InitUpload failed, CANopen error code 0xffffffff
|
|
D (228844) canopen: ReadSDO #30 0x1000.00: InitUpload failed, CANopen error code 0xffffffff
|
|
D (238384) canopen: ReadSDO #87 0x1000.00: InitUpload failed, CANopen error code 0xffffffff
|
|
|
|
This means one CANopen node was found, and some non-CANopen frames were
|
|
received on IDs 0x580 +23, +25, +27, +30 and +87.
|
|
|
|
|
|
Great! What now?
|
|
----------------
|
|
|
|
As you now know there's a CANopen node, you can look for documentation on it.
|
|
You can also try to access more default SDOs to see if you can control and
|
|
configure the node.
|
|
|
|
If you're lucky, the device will provide its own EDS file at SDO 1021.00. You
|
|
can check that by issuing…
|
|
|
|
copen … readsdo <nodeid> 1021 0
|
|
|
|
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:
|
|
https://www.can-cia.org/standardization/specifications/
|
|
|
|
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 or 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.
|
|
|
|
Have fun!
|