calumroy/CANopen.md

Last active July 16, 2023 11:57

Star (4) You must be signed in to star a gist
Fork (1) You must be signed in to fork a gist

Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/calumroy/c8cc57f8b2547782abe6.js"></script>
Save calumroy/c8cc57f8b2547782abe6 to your computer and use it in GitHub Desktop.

Raw

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.

Author

calumroy commented May 16, 2019 •

edited

Loading

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