CANopen.md

CANopen

Detailed information about CANopen can be found here; http://www.canopensolutions.com/english/about_canopen/about_canopen.shtml

A standardised CAN network protocol used in the auto and manufacturing industry. CANopen uses a normal CAN bus but it is a network protocol defining how the CAN packets should look. It allows speed of upto 1Mbit per second and has many easy to use (though often expensive) software configuration suites and CAN bus monitoring programs. The advantage of using CANopen standard over just a simple CAN bus (where the user defines each can packet) is that the CAN bus is easier to maintain and modules which support CANopen are easier to setup. Other CAN bus standards are;

• J1939 for the automotive industry (usually found in cars, bikes).
• NEAM2000 used for the marine industry such as boat engines and steering assemblies.

Software

• CANopen Configurator (CANopenConf) This Software is used to program the axiomatic input and output modules that connect to the can bus. The software can only program one device at a time. It is a licensed software program, it also must be used with one of TK's proprietary CAN to usb adapters.

• CANtrace
  Software used to view a live can bus.

Hardware

• CAN to USB adapter There is a range of CAN to USB adapters. PEAK CAN to USB can be used with a range of programs, some programs make it easier to configure an axiomatic controller. Kvaser CAN to USB adapter is unfortuantely very expensive (+$1000) but it can be used with CANopenConf tool to change an axiomatic settings. See http://www.tke.fi/service-tools/conftool

Files

• .eds
  These files are provided by the manufacture of the CANopen devices. They show all the meanings of the memory addresses for tat particular device.
• .dcf These files are actually .eds files that have been edited for a particular device. A device can be configured to expect certain TPDO packets containing certian information and to send certian RPDO packets. The .DCF file can setup a CANopen device to respond to events or inputs in a certain way e.g send a TPDO when one of the analogue inputs becomes larger then a certian value ect.
• .dbc
  These files define what messages are on a CANopen CAN bus and how the messages are structured. They are used by various CAN snoop programes to decode CAN messages and data and display it in an easy to use manner.

Starting the CAN bus.

By default CANopen devices start in an idle state. There is a standardized message that is required to start the CANopen devices.

This is easily sent via a master CANopen node or a CANopen analyser program such as CANtrace.

To start a can bus the CAN message (0x = hex) CAN ID 0x00 CAN Data 0x0100 can be sent.

To stop a can bus send the CAN message CAN ID 0x00 Can Data 0x0200.

CAN ID 00 is an ID used to indicate a broadcast message. All CAn devices receive these messages.

To start a specific CANopen node send the can message ID0x00 0x02 + nodeId e.g for node 11 = 0x0B send CANID=0x00 Bytes=0x01 0x0B

To stop a specific CANopen node send the can message ID0x00 0x02 + nodeId e.g for node 11 = 0x0B send CANID=0x00 Bytes=0x02 0x0B

To reset a particular node use ID0x00 Data 0x82 + nodeId. e.g for node 11=0x0B send CANID=0x00 Bytes=0x82 0x0B To reset just the comms of a particular node use 0x81 instead of 0x82 and include the node as above.

CANopen ID's

The following table shows the identifier allocation of the Predefined Connection Set:

Communication object    COB-ID(s) hex	    Slave nodes

NMT node control	    000	                Receive only

Sync	                080	                Receive only

Emergency	            080 + NodeID	    Transmit

TimeStamp	            100	                Receive only

PDO	                    180 + NodeID        1. Transmit PDO
                        200 + NodeID        1. Receive PDO
                        280 + NodeID        2. Transmit PDO
                        300 + NodeID        2. Receive PDO
                        380 + NodeID        3. Transmit PDO
                        400 + NodeID        3. Receive PDO
                        480 + NodeID        4. Transmit PDO
                        500 + NodeID        4. Receive PDO	
                        
SDO	                    580 + NodeID        Transmit
                        600 + NodeID	    Receive
                        
NMT node monitoring     700 + NodeID	    Transmit
(node guarding/heartbeat)

LSS	                    7E4                 Transmit
                        7E5	                Receive

SDOs and PDOs are always used in pairs (i.e. to transmit and to receive), where the rule is that the node on the lower (and therefore higher priority) COB-ID transmits and on the higher (i.e. lower priority) COB-ID receives.

SDO

Specific communication objects, so-called "service data objects" (SDOs) are used for direct access to CANopen devices. With these "service data objects", object dictionary entries can be read and written, where communication always takes place as a logical 1:1 connection (peer-to-peer) between two nodes (e.g. a configuring node and a node to be configured) . As the data transfer is carried out via such a connection as an acknowledged service, this means that two CAN messages per connection are required: one message for the request to the network node (SDO request or "Client SDO") and a second for the response (SDO response or "Server SDO") of the node.

AXIOMATIC CONTROLLERS

These controllers can be connected to CANopen networks and used to control inputs and outputs for valves and a range of devices.

They are set up with a default setting determining what CAn messages to send out and what the CAN bus settings are (eg 125Kbits). To change the default settings a CAN commercial program such as CANopen Configurator can be used or an open source alternative such as CAN festival with a peak usb to can adapter can be used.

Using CANopenSocket on Ubuntu

This opensource project can be used to to Read, Write and Run a CANopen network.
It can write SDO to any node on the CANopen network. It works with many USB adapters such as PEAK's USB to CAN adapter.
This is the best free way I have found so far to setting up CANopen networks.

See this github project for information about setting up
https://github.com/CANopenNode/CANopenSocket/blob/master/README.md

You will need to install the PEAK Can drivers for linux from here and setup the can interface for CANopenSocket to use.
Do the following

- download the driver peak-linux-driver-7.4.tar.gz from our linux website and copy it into your home directory.

- Install libpopt-dev: sudo apt-get install libpopt-dev
- Install g++: sudo apt-get install g++
(only necessary to build the chardev test tool transmittest)

- unpack the driver: tar -xzf peak-linux-driver-7.4.tar.gz
- cd peak-linux-driver-7.4
- make clean
- make
- sudo make install
- sudo modprobe pcan
- check with cat /proc/pcan that the driver was successfully installed.

*------------ PEAK-Systems CAN interfaces (http://www.peak-system.com) -------------
*-------------------------- Release_20110912_n (7.4.0) ----------------------
*------------- [mod] [isa] [pci] [dng] [par] [usb] [pcc] [net] --------------
*--------------------- 1 interfaces @ major 250 found -----------------------
*n -type- ndev --base-- irq --btr- --read-- --write- --irqs-- -errors- status
32 usb can0 30520000 255 0x001c 00000000 00000000 00000000 00000000 0x0000

Now we are ready to install the SocketCAN Tools:

- goto home directory again:
cd
- Install git:
sudo apt-get install git
- Get the SocketCAN Tools:
git clone https://github.com/linux-can/can-utils 
- build and install the tools:
cd can-utils
make
sudo make install

Set the network up:
sudo ifconfig can0 up

Test the communication with candump:
candump can0

-available tools are:
candump
cangen 
cansend
canbusload
canecho
canlogserver 
cansniffer
canfdtest 
canplayer

Setup a can dump

See above use the command

sudo ifconfig can0 up
candump can0

Setup master node

Once the can0 interface is running and you can see in terminal all can communication then you can setup a master node on the network.

Setup a master node with id 101 (in hex 0x65)

cd CANopenSocket/canopend
 ./canopend can0 -i 101 -c ""

Write to a CANopen devices object directory OD.

This example shows how to write to an axiomatic controller's OD with an can id of 105.
The writing is done via SDO messages from the master to the slave.
We also have to write to the slave to save our new parameters which have been written (otherwise they are forgotten on a power reset).

Change the heartbeat rate to once per 5 seconds

./canopencomm [1] 105 write 0x1017 0 u16 5000

Change the TPDO output rate to a timer event and specify a rate of 1Hz.

./canopencomm [1] 105 write 0x1800 2 u8 254 
./canopencomm [1] 105 write 0x1800 5 u16 1000 

Save the parameters so they aren't forgotten by the axiomatic controller

./canopencomm 105 w 0x1010 1 u32 0x65766173

The above commands if successful should return

[1] OK

We can also setup other nodes as well as specifying storage files for OD files.

View .eds files use CANopenSockets .html to view and edit .eds files. See CANopenSocket/canopend/CANopenSocket.html

COPBrowser

This is a free program that works on both linux and Windows. It can read and write .eds and dcf files to the CANopen device.

This program works with the PEAK USB adapter. For windows you must download the
Pcan_usb.dll and PCANBasic.dll drivers and put them in the directory containing the COPBrowser .exe program.

You can then select the peak usb adapter and baud rate.

After this open a .eds file for a specific device. Also select the node ID of the device whose .eds file you want to read and write to. Note you can scan the can network for node ID's. You can then read and write specific objects to that node.

Setting the PDO Mapping of a CANopen device

Each CANopen device has a set of CAN id's that correspond to different CAN messages that the devices either receives (RPDO messages) or transmits (TPDO messages). To set what the CANopen device expects to receive (TPDO) and what it will send (RPDO) the .eds files can be modified (they become .dcf files then). TEach CANopen device can receive up to 4 TPDO and send up to 4 RPDO messages. These messages have settings that are stored in a CANopen devices memory (object directory OD).

For example the Axiomatic digital hydraulic valve module (AX021301) is set by default to send a RPDO1 message containing different information about it's 6 digital outputs and 5 inputs. See the picture below taken from the device manual.

The output TPDO message is 8 bytes long and each byte represents what is in the modules memory address at the above locations.
This memory mapping can be changed by altering the values stored in the OD at address 1A00.

For example;
At memory address 1A00 byte3 we find by default the value 0x22500108. This means that byte 3 of TPDO1 contains the value in the OD at the address 2250 Sub Index 01 (each memory address holds multiple sub entries storing bytes of data). The last 08 value means take 8 bits (1 byte) from address 2250 sub Index 1 as the value to put into the TPDO1 message byte 3.
Note that from the user manual address 2250 sub index 1 stores the measured output current for the digital output number 1. This is what is sent in part of the TPDO message. We could change this mapping so other different values stored in different OD address are sent in the TPDO1 can message.

Manual SDO Communications

If we wanted to send raw CAn messages to a CANopen device to read and write values to the object directory here is the procedure for doing so.

SDO Read Command

Note to read some objects the device may need to be stopped or in pre-operational mode.
The CAN message ID used by a device to receive an SDO command is 0x600 + nodeID
The SDO CAN message data to send to the Can device to tell it to respond with the data in the selected data object address is:

Can header	rtr	len	Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x600 + node	0	8	Command	Index	Index	Sub Index	Data	Data	Data	Data

NOTE Data is in little endian format.
e.g To read from node 0x16 address 0x1800 sub index 1 send the following CAN message:

Can header	rtr	len	Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x616	0	8	0x40	0x00	0x18	0x01	0x00	0x00	0x00	0x00

The node ID 0x16 should respond if successful with the following can message.

Can header	rtr	len	Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x580 + node	0	8	0x43	0x00	0x18	0x01	0x96	0x01	0x00	0x40

This means the actual data stored at address 0x1800 was 0x40000196
If it was unsuccessful then the first byte in the response would be 0x80

If you want to read less then 4 bytes use the following read commands instead. This is the case as some obects are not 4 bytes long and cannot be read using the 0x40 command

0x40 = read 4 bytes
0x47 = read 3 bytes
0x4B = read 2 bytes
0x4F = read 1 byte

The returned responses first byte 0x43 indicates how many bytes where returned.
the 0x430x43 = 0b1000011 -----> The n two bits are zero meaing no bytes are empty in the response.
If the response was 0x4B = 0b1001011 ----> The 1011 means n = 0b10=2 and n is the number of n is the number of bytes in the data part of the message which do not contain data, only valid if e and s are set. e and s are set in this case 0b11

Byte Nr	Byte 0	Byte 1-2	Byte 3	Byte 4-7
Length	3 bits | 1 bit | 2 bits | 1 bit | 1 bit	2 bytes	1 byte	4 bytes
Meaning	ccs=1 | reserved(=0) | n | e | s	index	subindex	data

ccs is the client command specifier of the SDO transfer, this is 0 for SDO segment download, 1 for initiating download, 2 for initiating upload, 3 for SDO segment upload, 4 for aborting an SDO transfer, 5 for SDO block upload and 6 for SDO block download
n is the number of bytes in the data part of the message which do not contain data, only valid if e and s are set
e, if set, indicates an expedited transfer, i.e. all data exchanged are contained within the message. If this bit is cleared then the message is a segmented transfer where the data does not fit into one message and multiple messages are used.
s, if set, indicates that the data size is specified in n (if e is set) or in the data part of the message
index is the object dictionary index of the data to be accessed
subindex is the subindex of the object dictionary variable
data contains the data to be uploaded in the case of an expedited transfer (e is set), or the size of the data to be uploaded (s is set, e is not set)

SDO Write Command

The SDO CAN message data to send to the Can device to tell it to write the given data into the selected data object address is:

Can header	rtr	len	Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x600 + node	0	8	Command	Index	Index	Sub Index	Data	Data	Data	Data

Where the command is:

    0x23 = write 4 bytes
    0x27 = write 3 bytes
    0x2B = write 2 bytes
    0x2F = write 1 byte

NOTE Data is in little endian format.
e.g To write a 1 to node 0x47 address 0x61A0 sub index 1 send the following CAN message:

Can header	rtr	len	Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x647	0	8	0x2F	0xA0	0x61	0x01	0x01	0x00	0x00	0x00

The node ID 0x47 should respond if successful with the following can message.

Can header	rtr	len	Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
0x5C7	0	8	0x2F	0xA0	0x61	0x01	0x01	0x00	0x00	0x00

If it was unsuccessful then the first byte in the response would be 0x80

CANopen updating the TDPO mapping parameters

The TDPO mapping parameters in an CANopen devices data directory specify which memory address will be placed in the CAN message TDPO's and sent by the device. Unlike most parameters that can be changed when the deviec is in operational or pre-operational mode to change the mapping a specific sequence has to be performed outlined below.

The CiA 301 application layer specification requires a dedicated re-mapping procedure that involves five steps:

1. "Destroy" the transmit process data object (TPDO) by setting the valid bit to 1b of sub-index 01h of the TPDO communication parameter.
2. Disable PDO mapping by setting the sub-index 00h of the PDO mapping parameter to 00h.
3. Modify PDO mapping by changing the values of the corresponding sub-indices of the PDO mapping parameters.
4. Enable PDO mapping by setting the sub-index 00h to the number mapped process data.
5. "Create" a TPDO by setting the valid bit to 0b of sub-index 01h of the TPDO communication parameter.

The actual write to the mapping object can only be done after the COB-ID is destroyed, and sub–index 0 of the mapping objects are written as ‘0’

 

Example reprogramming PDO on AX030501

 

ID E R Len  D0  D1  D2  D3  D4  D5  D6  D7

67F       8  40  00  14  01  00  00  00  00

5FF       8  43  00  14  01  7F  02  00  40

67F       8  23  00  14  01  7F  02  00  80                   ‘destroy’ RPDO1, write msb of COB-ID as ‘1’ (1400sub1 = 8000027f)

5FF       8  60  00  14  01  00  00  00  00                   success                   

67F       8  40  00  16  00  00  00  00  00 

5FF       8  4F  00  16  00  04  00  00  00

67F       8  2F  00  16  00  00  00  00  00                   write number of mapping entries for RPD0 1 as ‘0’ (1600sub0 = 0)

5FF       8  60  00  16  00  00  00  00  00                   success

67F       8  40  00  16  01  00  00  00  00 

5FF       8  43  00  16  01  10  01  00  73

67F       8  23  00  16  01  10  01  00  73                   write RPDO1 mapping entry 1 as 73000110 (1600sub1 = 73000110)

5FF       8  60  00  16  01  00  00  00  00                   success

67F       8  40  00  16  00  00  00  00  00

5FF       8  4F  00  16  00  00  00  00  00

67F       8  2F  00  16  00  04  00  00  00                   write number of mapping entries for RPDO1 back to ‘4’ (1600sub0 = 4) 

5FF       8  60  00  16  00  00  00  00  00                   success

67F       8  40  00  14  01  00  00  00  00 

5FF       8  43  00  14  01  7F  02  00  80

67F       8  23  00  14  01  7F  02  00  40                    ‘repair’ RPDO1, write msb of COB-ID as ‘0’  (1400sub1 = 4000027F)

5FF       8  60  00  14  01  00  00  00  00                   success

67F       8  40  03  14  01  00  00  00  00

5FF       8  43  03  14  01  7F  05  00  80                    RPD03 COB-ID is already ‘destroyed’ by default (1403sub1 = 8000057F)

67F       8  40  03  16  00  00  00  00  00

5FF       8  4F  03  16  00  00  00  00  00                   RPDO3 number of mapping entries is ‘0’ by default (1603sub0 = 0)

67F       8  40  03  16  01  00  00  00  00

5FF       8  43  03  16  01  00  00  00  00

67F       8  23  03  16  01  10  02  00  73                    write RPDO3 mapping entry 1 as 73000210 (1603sub1 = 73000210)

5FF       8  60  03  16  01  00  00  00  00                  success

67F       8  40  03  16  00  00  00  00  00  

5FF       8  4F  03  16  00  00  00  00  00

67F       8  2F  03  16  00  01  00  00  00                   write number of mapping entries for RPDO3 to ‘1’ (1603sub0 = 1)  

5FF       8  60  03  16  00  00  00  00  00                    success

67F       8  40  03  14  01  00  00  00  00

5FF       8  43  03  14  01  7F  05  00  80

67F       8  23  03  14  01  7F  05  00  40                   ‘repair’ RPDO3, write msb of COB-ID as ‘0’  (1403sub1 = 4000057F)

5FF       8  60  03  14  01  00  00  00  00                   success

67F       8  23  10  10  01  73  61  76  65                   SAVE all parameters

5FF       8  60  10  10  01  00  00  00  00                   success

 

Note on AX021301

To start TPDO2 transmitting you need to write the value ‘400002ff’ into Object 1801, sub-index 1 (TPDO2 communication paratmer – cobID).

 

This is due to a mistake in the software that has the default value for this object as “C00002ff”.

 

Actually the value can end with 280 + node-ID if you are using a different node-ID then the default 7F.  The important part is that the 31st bit be set to 0 and not to 1.  Changing the MSB to ‘40’ and not ‘C0’ will accomplish this.

 

Remember to write the “store parameters” command to object 1010.