CANopen

Network Management is oriented towards CANopen devices and follows a master-slave structure. NMT requires a CANopen device in the network that performs the role of the CANopen master. All other devices have the role of the NMT slave. Each NMT slave can be addressed via its individual node-lD in the range from [1-127]. NMT services can be used to initiate, start, monitor, reset or stop CANopen devices. 

In doing so, the controller follows the state diagram shown in the following figure. The "lnitialization" state is only reached after switching on or by sending a "Reset Communication" or "Reset Node" NMT command. The "Pre-Operational" state is automatically activated after initialization. 

The "Network Management" message has CAN-ID 0. A message is always two bytes lang and has the following structure: 

The Synchronization object is used to simultaneously validate the time of PDO data for all devices on the bus. The sync message is structured as follows: 

For SYNC operation, transmission mode (Transmission Type) 0 is normally used for the RX-PDOs (data are valid with the next SYNC); for TX-PDOs, a transmission mode between 1 and 240 is selected. (Details: see <link knowledge-base-article canopen-motors-controllers _top>Process Data Object (PDO)). 

After receiving a SYNC message, there is a time window ("synchronous window") within which PDO messages can be sent and received. lf the time of the window has elapsed, all devices must stop sending PDOs. 

A typical CAN-SYNC operation is divided into four phases (see also the following figure):

1. The SYNC message is received. The previously received RX-PDO data are thereby copied to the object dictionary (if present). At that time, the data are also sampled and copied to the TX-PDOs and the sending of these messages initiated.
2. The TX-PDOs are then sent by all slaves on the bus.
3. Afterwards, the PDOs are sent by the CANopen master. After the "synchronous window length" time has elapsed, no further PDOs are permitted.
4. SDO messages can be exchanged at the latest when the "synchronous window" is closed again.
   
   
   

A message of type "Emergency" is sent whenever an error occurs in the controller that was not caused by an SDO access. This service is unconfirmed and is sent with CAN-ID 80_h+Node-lD. 

The emergency message is structured as follows: 

Expedited Transfer

This method is used to write (download) or read (upload) values in objects of type (UN)SIGNEDS, INTEGER16 oder INTEGER32 in the object dictionary. This service is confirmed, i.e., each access is answered with data, with a confirmation or with an error message. 

SDO Download
An expedited SDO message for writing data in the object dictionary of the server is structured as follows:

Here, the <CMD> byte is dependent on the length of the data that are to be written. <CMD> can be one of the following values: 

• 1 byte data length: 2F_h 
• 2 byte data length: 2B_h 
• 3 byte data length: 27_h 
• 4 byte data length: 23_h

The <Data> field is written with the data that are to be written; the LSB of the data is entered in byte 4. 

The answer from the server is either a confirmation of the write operation or an error message (structure of the messages: see following figure). In the latter case, the reason for the error is also sent with the data (see list of the SDO error messages in section <link knowledge-base-article canopen-motors-controllers _top>SDO error messages). 

Example 
Set object 607A_h:00_h (target position, SIGNED32) to value 3E8_h (=1000_d) of a controller with node-ID 3: 

603 | 23 7A 60 00 E8 03 00 00  

• Byte 1 (23_h): SDO expedited download, 4 bytes of data (SIGNED32)
• Bytes 2 and 3 (7A_h 60_h): index of object is 607A_h 
• Byte 4 (00_h): subindex of object is 00_h 
• Bytes 5 to 8 (E8_h 03_h 00_h 00_h): value of object: 000003E8_h 

lf successful, the controller responds with this message:

583 | 60 7A 60 00 00 00 00 00

SDO upload 
A CAN message for reading an object from the object dictionary has the following structure:

The server responds with one of the following messages:  

Rx configuration

To configure an RX-PDO, three object categories in the object dictionary must be taken into account: 

1. The objects that describe the functionality of the mapping.
2. The objects that describe the content of the mapping.
3. The objects that are to receive the received data.

Configuration of the functionality (communication parameter) 
The configuration of the first mapping is stored in the subindices of object 1400h. The second mapping is configured in 1401_h and so on. In the following, we refer to 140N_h. Here, the configuration affects the COB-1D of the PDO message and the transfer type. 

Objects 140N_h have only three subindices: 

• Subindex 0 (max. subindex): Total number of subindices
• Subindex 1 (COB-1D): The COB-1D is stored here. For PDO mappings 1-4 (1600_h-1603_h), the CAN-1D is fixed depending on the node-1D and only the valid bit (bit 31) can be set in the COB-1D. From 1604_h-1607_h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table ) as can the valid bit. The change of a COB-ID does not take effect until afterthe controller or communication is restarted (see <link knowledge-base-article canopen-motors-controllers _top>Network Management (NMT)). 

• Subindex 2 (transmission type): A number is stored in this subindex that defines the time at which the received data become valid. The number and the corresponding meaning can be found in the following table.

Content of a mapping

The configuration of the content of a mapping is structured as follows (see also the following figure as an example): 

• All subindices of a configuration object belang together. Thus, 1600_h with all subindices describes the first mapping, 1601_h the second RX-PDO mapping, etc.
• Subindex 00_h specifies how many objects are in a mapping. lt simultaneously specifies how many of the subindices are valid. lf object 1600_h:00_h is set to "0", RX mapping is thereby completely switched off. In the example shown in the following figure, two objects are thus mapped; object 1600_h:03_h and 1600_h:04_h is, therefore, not active (shown in gray).
• Each subindex from 1600_h:01_h to 1600_h:0F_h describes one target of the mapping sequentially and without gaps. The index, subindex and bit length are thereby encoded. Example from the following figure: The first two bytes of the message are to be written in object 6040_h:00_h. In hexadecimal notation, the content of 1600_h:01_h then consists of
  <Index><Subindex><Bit length>
  or 60400010. The second mapping (1600h:02_h) contains the entry 607A0020. Thus, it maps the following four bytes (=20_h ßit) in object 607A_h:00_h 

TX configuration

To configure an TX-PDO, three object categories in the object dictionary must be taken into account:

1. The objects that describe the functionality of the mapping.
2. The objects that describe the content of the mapping.
3. The objects that are to receive the data that are to be sent.

Also note that the time at which the data are copied to the TX-PDO message and the time of sending do not need to be the same (dependent on mode). 

Configuration of the functionality (communication parameter) 

The configuration of the functionality of the first mapping is stored in the subindices of object 1800_h. The second mapping is configured in 1801_h and so on. In the following, we refer to 180N_h. Here, the configuration affects the COB-ID of the PDO message and the transfer type. 

Objects 180N_h have the following subindices: 

• Subindex 0 (max. subindex): Total number of subindices
• Subindex 1 (COB-ID): The COB-ID is stored here. For PDO mappings 1--4 (1A00_h-1A03_h), the CAN-ID is fixed depending on the node-ID and only the valid bit (bit 31) can be set in the COB-ID. From 1A04_h-1A07_h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table ) as can the valid bit. A COB-ID change does not take effect until after the controller or communication is restarted (see Network Management (NMT)).

• Subindex 2 (transmission type): A number is stored in this subindex that defines the time at which the data are to be copied into the PDO message and when this is to be sent. The number and the corresponding meaning can be found in the following table. Below, we refer to an Event that can trigger the copying and/or sending of the data. This Event consists of three events, which can be considered independently of one another:
  
  - The NMT state machine is switched to "operational".
  - The current data have changed with respect to the last PDO message.
  - The Event Timer has expired (see 180N_h:5).
  
  lf the Event Timer is used, it is handled independently of the changes; the Event Timer is not restarted until the current event timer expires, not because of another Event. 

• Subindex 3 (inhibit time): This subindex contains a time lock (see following figure). This can be used to set a time that must elapse after the sending of a PDO before the PDO is sent another time. This time only applies for asynchronous PDOs. This is intended to prevent PDOs from being sent continuously if the mapped object constantly changes.
• Subindex 4 (compatibility entry): This subindex has no function and exists only for compatibility reasons.
• Subindex 5 (event timer): This time can be used to trigger an Event which handles the copying of the data and the sending of the PDO.
• Subindex 6 (sync start value): Here, the start value of the Sync Counter is entered beginning with which the s/ave is to initially respond to the sync and send the PDO. Not globally activated until a value greater than 1 is set in 1019_h Synchronous Counter Overflow Value.

Content of mapping

The configuration of the content of a mapping is structured as follows (see the following figure as an example): 

• All subindices of a configuration object belang together. Thus, 1A00_h with all subindices describes the first mapping, 1A01_h the second TX-PDO mapping, etc.
• Subindex 00 specifies how many objects are in a mapping. lt simultaneously specifies how many of the subindices are valid. lf object 1A00_h:00_h is set to "0", TX mapping is thereby completely switched off. In the following example, two objects are thereby mapped in entries 1A00_h:01_h - 1A00_h:02_h - The objects in entries 1A00_h:03_h - 1A00_h:04_h are, thus, not mapped (shown in gray).
• Each subindex from 1A00_h:01_h to 1A00_h:0F_h respectively describes sequentially and without gaps (dummy objects can be used for gaps) one source of the mapping. The index, subindex and bit length are thereby encoded. Example from the following figure: The first two bytes of the message are to be read from object 6041_h:00_h. In hexadecimal notation, the content of 1A00_h:01_h then consists of <Index><Subindex><Bit Length>, or 60410010. The second mapping (1A00_h:02_h) contains the entry 60640020. Thus, it maps the following four bytes (corresponds to 32 bits) from object 6064_h:00_h in the TX-PDO message.

lf the CAN slave reaches the "Pre-Operational" NMT state (see following figure), the following message is sent to signal operational readiness.

Nodeguarding

This service is based on the fact that the NMT master sends an RTR message with CAN-ID 700_h + node­ID to the respective slave. The slave must then send a message as response; this message is structured as follows. Bit 7 alternates here on each transfer, thereby allowing one to determine if a message was lost. Entered in bits 6 to 0 is the current NMT status of the slave. 

With nodeguarding, there exist three time intervals (see also the following figure):

1. guard time: The time between two RTR messages. This can be different for each CAN node and is stored in the slave in object 100C_h:00 (unit: milliseconds)
2. live time factor: A multiplier for the guard time; this is stored in the CAN slave in object 1 00D_h:00 and can be different for each slave on the CAN bus.
3. possible live time: The time produced by multiplying guard time and live time factor.

Heartbeat

lf heartbeat is activated, the slave sends its NMT state to the CAN bus unprompted and cyclically. This service is activated by setting the Producer Heartbeat Time time in object 1017_h:00_h to a value other than zero. The message sent by the slave has the form shown below: