OVMS3/OVMS.V3/components/canopen/docs/Howto-detect-CANopen-nodes.txt

================================================================================
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!