1、CANopenPredefined Connection Set
To reduce the configuration workload of simple networks, CANopen defines a mandatory default identifier (CAN-ID) allocation table. These identifiers are available in the pre-operational state and can be modified through dynamic allocation. CANopen devices must provide the corresponding identifiers for the communication objects they support.
The defaultID allocation table is based on 11 bits of CAN–ID, which includes a 4-bit function code part and a 7-bit nodeID (Node-ID) part.
Node-ID is defined by the system integrator, for example, set via dip switches on the device. Node-ID ranges from 1~127 (0 is not allowed to be used).
The predefined connection set defines 4 receive PDO (Receive–PDO), 4 send PDO (Transmit–PDO), 1 SDO (occupying 2 CAN-ID), 1 emergency object, and 1 node error control(Node-Error-Control) ID. It also supports unconfirmed NMT-Module-Control services, SYNC and Time Stamp object broadcasting.
CANopen predefined master/slave connection set CAN identifier allocation table
Note:
◆ PDO/SDO send/receive is observed by the (slave) CAN node.
◆ NMT error control includes node guarding (NodeGuarding), heartbeat messages (Heartbeat), and boot-up protocol.
CANopen identifier allocation
ID address allocation table corresponds with the predefined master/slave connection set (set), as all peerID are different, so in reality, only one master device( knows all connected nodeID) can communicate with each connected slave node (up to 127 nodes) in a peer-to-peer manner. Two connected slave nodes cannot communicate with each other as they do not know each other’s nodeID.
Comparing the aboveID mapping and CAL mapping shows how specific functional CANopen objects map to CAL general CMS objects.
CANopen network CAN identifier (or COB-ID) allocation has 3 different methods:
◆ Use predefined master/slave connection set. The ID is default and does not require configuration. If supported, PDO data content can also be configured.
◆ Modify the PDO’s ID after power-up (in pre-operational state), using (predefined) SDO to modify at the appropriate location in the node’s object dictionary.
◆ Use CAL DBT service: nodes or slave nodes are initially referenced by their configurationID. NodeID can be configured by dip switches on the device or using CAL LMT service. When the network is initialized and started, the master node first establishes a dialogue with each connected slave device through “Connect_Remote_Node” report (which is a CAL NMT service). Once this dialogue is established, CAN communicationID (SDO and PDO) are allocated using CAL DBT service, which requires nodes to support extended boot-up.
CANopen Boot-up Process
During network initialization, CANopen supports extended boot-up and also supports a minimized boot-up process.
Extended boot-up is optional, while minimized boot-up must be supported by each node. Both types of nodes can coexist on the same network.
If ID allocation is done using CAL’s DBT service, nodes must support the extended boot-up process.
This can be represented using the node state transition diagram for these two initialization processes, as shown in Figure 3-3. The state diagram for extended boot-up has more states between pre-operational and operational states than the minimized boot-up.
CANopen minimized boot-up node state transition diagram
Note:
◆ The letters in brackets in Figure 3-3 indicate which communication objects can be used in different states.
a. NMT, b. Node Guard, c. SDO, d. Emergency, e. PDO, f. Boot-up
◆ State transitions (1-5 initiated by NMT service), NMT command word (in brackets):
1: Start_Remote_node (0x01)
2: Stop_Remote_Node (0x02)
3: Enter_Pre-Operational_State (0x80)
4: Reset_Node (0x81)
5: Reset_Communication (0x82)
6: Device initialization ends, automatically entersPre_Operational state, sending Boot-up message.
At any time,NMT service can put all or part of the nodes into different operational states.NMT service’s CAN message consists of CAN header(COB-ID=0) and two-byte data; the first byte indicates the requested service type(‘NMT commandspecifier’), the second byte is the nodeID, or 0 (addressing all nodes).
Devices that only support minimized boot-up are called minimal capability devices. Minimal capability devices automatically enter the pre-operational state after device initialization ends. In this state, parameter configuration can be done throughSDO andCOB-ID allocation.
After the device enters the ready state, communication will stop except forNMT service and node guarding service (if supported and activated). (Thus, ‘Stopped’ is one description of this state)