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.
-
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.
- 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
- .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.
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.
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.
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.
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: