CANopen services The CANopen stack offers the services listed in the following table; more detailed descriptions can be found in the respective chapters. Default CAN-ID Service Description in 000h Network Management (NMT) Section Network Management (NMT) 080h Synchronization Object Section Synchronization object (SYNC) 080h+Node-ID Emergency Section Emergency Object (EMCY) 180h+Node-ID TX Process Data Objects (PDO) Section Process Data Object (PDO) 200h+Node-ID RX Process Data Objects (PDO) 280h+Node-ID TX Process Data Objects (PDO) 300h+Node-ID RX Process Data Objects (PDO) 380h+Node-ID TX Process Data Objects (PDO) 400h+Node-ID RX Process Data Objects (PDO) 480h+Node-ID TX Process Data Objects (PDO) 500h+Node-ID RX Process Data Objects (PDO) 580h+Node-ID TX Service Data Objects (SDO) Section Service Data Object (SDO) 600h+Node-ID RX Service Data Objects (SDO) 700h+Node-ID BOOT-UP Protocol Section Boot-Up Protocol 700h+Node-ID Nodeguarding and Heartbeat Section Heartbeat and Nodeguarding The setting for the node-ID can be found in Position of the virtual rotary switch. Network Management (NMT) The network management 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-ID 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 "Initialization" 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. In object 1F80h, you can set whether the "Operational" state is automatically switched to afterwards, thereby allowing you to avoid sending an additional NMT command. Shown in the following table is an overview of the activity of the services in the respective states. Note that the Stopped state stops communication completely and only permits controller of the NMT state machine. Service Initializing Pre-Operational Operational Stopped PDO Active SDO Active Active SYNC Active Active EMCY Active Active BOOT-UP Active NMT Active Active Active The "Network Management" message has CAN-ID 0. A message is always two bytes long and has the following structure: Here, the <CMD> corresponds to one of the following bytes (see also the legend in the figure of the NMT state diagram): <CMD> Meaning 01h Switch to the "Operational" state 02h Switch to the "Stop" state 80h Switch to the "Pre-Operational" state 81h Reset Node 82h Reset Communication Completely restart the controller with the "Reset Node" command. Use the "Reset Communication" command to reset the CANopen settings and restart the communication. The value for <Node-ID> can be 00h; in this case, the NMT command applies for all devices on the CAN bus (broadcast). If a number not equal to zero is used, only the device with the corresponding node-ID is addressed. Example: If all devices on the CAN bus are to be switched to the "Stop" operating state, a broadcast with the "Switch to the Stop state" command can be used. The NMT message is structured as follows: 000 | 02 00 If only the device with node-ID 42 is to be completely restarted, the following CAN message is to be sent: 000 | 01 2A Synchronization object (SYNC) 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 usually 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 chapter 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. If the time of the window has elapsed, all devices must stop sending PDOs. The "synchronous window length" can be set in microseconds in object 1007h:00h. A typical CAN-SYNC operation is divided into four phases (see also the following figure): 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. The TX-PDOs are then sent by all slaves on the bus. Afterwards, the PDOs are sent by the CANopen master. After the "synchronous window length" time has elapsed, no further PDOs are permitted. SDO messages can be exchanged at the latest when the "synchronous window" is closed again. If the Sync Producer supports a Sync Counter, the sync message receives an additional 1-byte numerical value. This counter is increased by the value "1" per sent sync message and is reset each time the value 1019h Synchronous Counter Overflow Value is reached. For each TX-PDO, a start value of the Sync Counter can be defined in subindex 06h of the corresponding communication parameter (e.g., in 1800h:06h) beginning with which the slave is to respond to the sync for the first time and send the PDO. The function is not activated until a value greater than 1 is set in 1019h. Emergency Object (EMCY) 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 80h+Node-ID. The emergency message is structured as follows: A total of three error codes are transferred here: the "Emergency Error Code" (<EMCY Error Code>) the content of the "Error Register" object (1001h), E-REG the "Error Number" (E-Number) Error handling A module for error handling processes all errors that occur internally. Each error is classified into an error class. Each error that occurs is handled as follows: The bit that belongs to the error in the "Error Register" object (1001h) is set. Three pieces of information are then written together in the "Pre-defined Error Field" object (1003h:01): The Emergency Error Code The Error Register The manufacturer-specific error code If no further errors are pending, the following message is sent: 80 + Node-ID | 00 00 E-REG E-Number 00 00 00 00 In object 1029h, you can configure whether and how the controller is to change its NMT state in case of an error. Service Data Object (SDO) A "Service Data Object" permits read or write access of the object dictionary. In the following, the owner of the object dictionary is referred to as the "server"; the CAN node – which wants to request or write the data – is referred to as the "client". An "upload" refers to the reading of a value of an object from the object dictionary; a "download" refers to the writing of a value in the object dictionary. In addition, the following abbreviations are used in the diagrams: <IDX>: Index of the object that is to be read or written in the object dictionary; the LSB of the index is in byte 1 here. Example: The statusword of the controller has index 6041h; byte 1 is then written with 41h and byte 2 with 60h. With Expedited Transfer, the SDO answer contains the same index as that of the request. <SUBIDX>: Subindex of the object in the object dictionary from 00h to FFh. With Expedited Transfer, the answer of the SDO message of the controller also contains the subindex of the request. Because CAN messages of type SDO contain a large amount of metadata, you should only use SDO messages to configure the controller. Should it be necessary to cyclically exchange data during running operation, use CANopen messages of type PDO (see subsection Process Data Object). The SDO transfers are divided into three types of access: "expedited transfer" for transferring objects with up to four bytes. "normal transfer" for transferring any number of bytes, whereby each CAN message is confirmed individually. "block transfer" is also for any number of bytes; here, a given block of CAN tickets is confirmed at once. An SDO message is sent to CAN-ID 600h + node-ID, the answer comes from CAN-ID 580h + node-ID. Expedited Transfer This method is used to write (download) or read (upload) values in objects of type (UN)SIGNED8, 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: 2Fh 2 byte data length: 2Bh 3 byte data length: 27h 4 byte data length: 23h 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 SDO error messages). Example: Set object 607Ah:00h (target position, SIGNED32) to value 3E8h (=1000d) of a controller with node-ID 3: 603 | 23 7A 60 00 E8 03 00 00 Where Byte 1 (23h): SDO expedited download, 4 bytes of data (SIGNED32) Bytes 2 and 3 (7Ah 60h): index of object is 607Ah Byte 4 (00h): subindex of object is 00h Bytes 5 to 8 (E8h 03h 00h 00h): value of object: 000003E8h If 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. The length of the data is encrypted in the <CMD> of the answer: 1 byte data length: 4Fh 2 byte data length: 4Bh 3 byte data length: 47h 4 byte data length: 43h The LSB of the data is again in byte 4 here. In case of an error, the reason for the error is also specified in the data (see list of SDO error messages in SDO error messages). Example: To read the "statusword" object (6041h:00) from the object dictionary, it suffices to send the following message (always 8 bytes): 603 | 40 41 60 00 00 00 00 00 The controller generally responds with the following message: 583 | 4B 41 60 00 40 02 00 00 Where Byte 1 (4Bh): SDO expedited upload, 2 bytes of data (UNSIGNED16) Bytes 2 and 3 (41h 60h): index of object is 6041h Byte 4 (00h): subindex of object is 00h Bytes 5 to 6 (40h 02h ): value of object: 0240h Bytes 7 to 8 (00h 2h h h): empty. An SDO message always consists of 8 bytes. Normal Transfer Unlike "expedited" CANopen transfer, "normal transfer" is not limited to maximum four bytes. With this type of transfer, the content of multiple messages is grouped together with respect to content; such a block of messages is referred to in the following as a "transfer". Each message within a transfer is confirmed individually here. Note: If your CANopen master does not support normal transfer, there is another way to access objects of data type String: each string can be read out character by character with an SDO upload to subindex 1 and the following subindicies. SDO upload Shown in the following figure is the procedure for an "SDO upload" (client requests that the content of an object be sent to it). The transfer is broken down into two phases: an initialization phase and a transfer phase. As with an "expedited transfer", the upload begins with the client sending an "Init SDO Update" to the server (see following figure). The answer for a "normal transfer" does not contain the quantity of bytes to be received encoded in the <CMD>. It is instead entered in the data range as can be seen in the following figure in the <DATA LENGTH> area. The initialization is thereby concluded; all that remains is the upload of the data. A data packet is requested with the following SDO request: Byte 0 with command <CMD> is structured as follows: The bit with designation t alternates with each request ("toggle bit"). It begins each transfer with 0, even if the previous transfer was aborted. The controller responds to the above message with the data, whereby the message is structured as follows: Byte 0 with <CMD> is structured as follows: The bits have the following meaning here: t (toggle bit) The bit alternates with each message sequence; it does not change within a sequence between "request" and "response". n (number of bytes) These three bits specify how many bytes contain no data. Example: If bits 2 and 1 are set to 0 and bit 3 is set to 1, then 011b = 03d bytes are not valid. This, in turn, means that byte 1 to byte 4 contain allowed values and byte 5 to byte 7 should be disregarded. c (more segments) If no further SDO segments are sent and this is the last segment, the bit is set to 1. Example: In this example, the "Manufacturer Software Version" object (100Ah) is to be read. The node-ID of the node in this example is 3. The corresponding SDO message sequence is listed in the following table. The string that is to be read out varies from controller to controller. COB-ID Data Description 603h 40 0A 10 00 00 00 00 00 Init Upload; Index: 100Ah; Subindex: 00 583h 41 0A 10 00 11 00 00 00 Init Upload; Size: indicated; transfer type: normal; Num of bytes: 17; Index: 100Ah; Subindex: 00 603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set 583h 00 46 49 52 2D 76 31 37 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: not set 603h 70 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: set 583h 10 34 38 2D 42 35 33 38 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: set 603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set 583h 09 36 36 32 00 00 00 00 Upload Segment Conf.; More segments: no (last segment); num of bytes: 3; Toggle bit: not set 46 49 52 2D 76 31 37 34 38 2D 42 35 33 38 36 36 32 This corresponds to string: "FIR-v1748-B538662" Aborting the SDO transfer Both the server and the client are authorized to abort the current transfer. To do this, an "Abort SDO Transfer" must be sent; this is depicted in the following. After receiving the message, the SDO transfer is considered ended; the service is not confirmed. A new SDO transfer must then be started from the very beginning. Transfer of the <ERROR CODE> is optional; the controller does not evaluate the code. SDO error messages In case of an error, an error number specifying the reason for the error is also sent in the data area. Error Code Description 05030000h toggle bit not changed: Valid only with "normal transfer" or "block transfer". The bit, which is to alternate after each transfer, did not change its state. 05040001h command specifier unknown: Byte 0 of the data block contains a command that is not allowed. 06010000h unsupported access: If "complete access" was requested via CAN over EtherCAT (CoE) (is not supported.) 06010002h read only entry: An attempt was made to write to a constant or read-only object. 06020000h object not existing: An attempt was made to access a non-existing object (index incorrect). 06040041h object cannot be pdo mapped: An attempt was made to map an object in the PDO for which that is not permissible. 06040042h mapped pdo exceed pdo: If the desired object were to be attached to the PDO mapping, the 8 bytes of the PDO mapping would be exceeded. 06070012h parameter length too long: An attempt was made to write to an object with too much data; for example, with <CMD>=23h (4 bytes) to an object of type Unsigned8, <CMD>=2Fh would be correct. 06070013h parameter length too short: At attempt was made to write to an object with too little data; for example, with <CMD>=2Fh (1 byte) to an object of type Unsigned32, <CMD>=23h would be correct. 06090011h subindex not existing: An attempt was made to access an invalid subindex of an object; the index, on the other hand, would exist. 06090031h value too great: Some objects are subject to restrictions in the size of the value; in this case, an attempt was made to write an excessively large value to the object. For example, the "Pre-defined error field: Number of errors" object for 1003h:00 may only be set to the value "0"; all other numerical values result in this error. 06090032h value too small: Some objects are subject to restrictions in the size of the value. In this case, an attempt was made to write a value that is too small to the object. 08000000h general error: General error that does not fit in any other category. 08000022h data cannot be read or stored in this state: The parameters of the PDOs may only be changed in the "Stopped" or "Pre-Operational" state. Write access of objects 1400h to 1407h, 1600h to 1607h, 1800h to 1807h and 1A00h to 1A07h is not permissible in the "Operational" state. Process Data Object (PDO) A message that only contains process data is referred to as a "Process Data Object" (PDO). The PDO is intended for data that need to be exchanged cyclically. The idea behind a PDO message is to remove all additional information (index, subindex and data length) from a CAN message and to only fill the CAN message with data. The source and target information for the PDO are stored separately in the so-called PDO mapping. PDOs can only be used if the NMT state machine is in the "Operational" state (see section Network Management (NMT)); the PDOs must be configured in the "Pre-Operational" NMT state. The controller supports a total of 8 independent PDO mappings; each corresponding PDO message can have a maximum of eight bytes (=64 bit) of user data. It is thereby possible to, for example, transfer two UNSIGNED32 values or one UNSIGNED32 and one UNSIGNED08; the message does not need to use all eight data bytes. The PDOs differ yet again in the configuration in the send and receive configuration. The receive configuration describes the processing for PDO messages that are sent, and the send configuration describes the PDO messages that are to be sent. RX configuration To configure an RX-PDO, you must take into account three object categories in the object dictionary: The objects that describe the functionality of the mapping. The objects that describe the content of the mapping. 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 1401h and so on. In the following, we refer to 140Nh. Here, the configuration affects the COB-ID of the PDO message and the transfer type. Objects 140Nh have only three subindices: Subindex 0 (max. subindex): Total number of subindices Subindex 1 (COB-ID): The COB-ID is stored here. For PDO mappings 1–4 (1600h–1603h), 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 1604h–1607h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table at the start of chapter CANopen services) as can the valid bit. The change of a COB-ID does not take effect until after the controller or communication is restarted (see Network Management (NMT)). Mapping COB-ID 1600h 200h + Node-ID 1601h 300h + Node-ID 1602h 400h + Node-ID 1603h 500h + Node-ID 1604h xxxh + Node-ID 1605h xxxh + Node-ID 1606h xxxh + Node-ID 1607h xxxh + Node-ID 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. 140Nh:02h Meaning 00h-F0h Synchronous: The data are buffered and not until the next SYNC message is received do they become valid and are they taken over into the object dictionary. F1h-FDh Reserved FEh, FFh Asynchronous: The data become valid when the PDO message is received and are taken over into the object dictionary. 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 belong together. Thus, 1600h with all subindices describes the first mapping, 1601h the second RX-PDO mapping, etc. Subindex 00h specifies how many objects are in a mapping. It simultaneously specifies how many of the subindices are valid. If object 1600h:00h 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 1600h:03h and 1600h:04h is, therefore, not active (shown in gray). Each subindex from 1600h:01h to 1600h:0Fh 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 6040h:00h. In hexadecimal notation, the content of 1600h:01h then consists of<Index><Subindex><Bit length>or 60400010. The second mapping (1600h:02h) contains the entry 607A0020. Thus, it maps the following four bytes (=20hBit) in object 607Ah:00h Dummy objects You can configure RX-PDOs so that more than one node can respond. In this case, it may be desirable for only part of the data contained in the PDO to be evaluated in one of the devices. For data not used locally, you can include a dummy object of one of the supported data types in the mapping of the PDO: Index Data type 0002h INTEGER8 0003h INTEGER16 0004h INTEGER32 0005h UNSIGNED08 0006h UNSIGNED16 0007h UNSIGNED32 TX configuration To configure a TX-PDO, you must take into account three object categories in the object dictionary: The objects that describe the functionality of the mapping. The objects that describe the content of the mapping. 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 1800h. The second mapping is configured in 1801h and so on. In the following, we refer to 180Nh. Here, the configuration affects the COB-ID of the PDO message and the transfer type. Objects 180Nh 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 (1A00h–1A03h), 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 1A04h–1A07h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table at the start of chapter CANopen services) 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)). Mapping COB-ID 1A00h 180h + Node-ID 1A01h 280h + Node-ID 1A02h 380h + Node-ID 1A03h 480h + Node-ID 1A04h xxxh + Node-ID 1A05h xxxh + Node-ID 1A06h xxxh + Node-ID 1A07h xxxh + Node-ID 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 180Nh:5). If 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. 180Nh:02h Meaning 0 Synchronous (acyclic): The data are copied to the TX-PDO upon arrival of the SYNC but are not sent until the Event. 01h-F0h Synchronous (cyclic): The data are copied upon arrival of the nth SNCY message and are sent immediately thereafter (n corresponds to the number 1 to 240, transmission type "1" sends the new data on each SYNC). F1h-FBh Reserved FCh RTR-Only (synchronous): The data are copied upon arrival of each SYNC message but are sent only upon request with an RTR message. FDh RTR-Only (event-driven): The data are copied to the TX-PDO message upon receipt of an RTR message and sent immediately thereafter. FEh, FFh The data are copied upon arrival of the Event and sent immediately. Subindex 3 (inhibit time): This subindex contains a time lock in 100 µs steps (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 (in ms) 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 slave is to initially respond to the sync and send the PDO. Not globally activated until a value greater than 1 is set in 1019h Synchronous Counter Overflow Value. Content of a 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 belong together. Thus, 1A00h with all subindices describes the first mapping, 1A01h the second TX-PDO mapping, etc. Subindex 00 specifies how many objects are in a mapping. It simultaneously specifies how many of the subindices are valid. If object 1A00h:00h is set to "0", TX mapping is thereby completely switched off. In the following example, two objects are thereby mapped in entries 1A00h:01h – 1A00h:02h. The objects in entries 1A00h:03h – 1A00h:04h are, thus, not mapped (shown in gray). Each subindex from 1A00h:01h to 1A00h:0Fh 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 6041h:00h. In hexadecimal notation, the content of 1A00h:01h then consists of <Index><Subindex><Bit Length>, or 60410010. The second mapping (1A00h:02h) contains the entry 60640020. Thus, it maps the following four bytes (corresponds to 32 bits) from object 6064h:00h in the TX-PDO message. Presetting The following configuration is preset: RX-PDO 1. Mapping (CAN-ID: 200h + Node-ID): 6040h:00h (controlword) 6060h:00h (mode of operation) 3202h:00h (motor drive submode select) 2. Mapping (CAN-ID: 300h + Node-ID): 607Ah:00h (target position) 6081h:00h (profile velocity) 3. Mapping (CAN-ID: 400h + Node-ID): object 6042h:00h (vl target velocity) 4. Mapping (CAN-ID: 500h + Node-ID): object 60FEh:01h (digital outputs) TX-PDO 1. Mapping (CAN-ID: 180h + Node-ID): 6041h:00h (statusword) 6061h:00h (Modes Of Operation Display) 2. Mapping (CAN-ID: 280h + Node-ID): 6064h:00h (Position actual value) 3. Mapping (CAN-ID: 380h + Node-ID): 6044h:00h (vl velocity actual value) 4. Mapping (CAN-ID: 480h + Node-ID): object 60FDh:00h (digital inputs) Changing PDO mapping You change the PDO mapping in the "Pre-operational" NMT state as follows: Deactivate the PDO by setting the Valid Bit (bit 31) of subindex 01h of the corresponding communication parameter (e.g., 1400h:01h) to "1". Deactivate the mapping by setting subindex 00h of the corresponding mapping parameter (e.g., 1600h:00h) to "0". Change the mapping in the desired subindices (e.g., 1600h:01h). Activate the mapping by writing the number of objects that are to be mapped in subindex 00h of the corresponding mapping parameter (e.g., 1600h:00h). Activate the PDO by setting bit 31 of subindex 01h of the corresponding communication parameter (e.g., 1400h:01h) to "0". Store the configuration by writing the value "65766173h" in 1010h:03h. Boot-Up Protocol If the CAN slave reaches the "Pre-Operational" NMT state (see following figure), the following message is sent to signal operational readiness. This service is unconfirmed; there is no response. Note: The boot loader sends its own boot-up message. This can be suppressed, see object 2007h:00 Heartbeat and Nodeguarding With the "Heartbeat" and "Nodeguarding" services (often also referred to as "Lifeguarding"), switched-off or hung devices on the CAN bus can be found. For this purpose, the NMT master cyclically requests a message with the current NMT state of the slave (Nodeguarding). The alternative is that each slave sends a message unprompted and cyclically (Heartbeat). A combination of Nodeguarding and Heartbeat is not permissible. Furthermore, it is recommended that Heartbeat be given preference over Nodeguarding, as Nodeguarding results in a higher load on the CAN bus. Nodeguarding This service is based on the fact that the NMT master sends an RTR message with CAN-ID 700h + 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): guard time: The time between two RTR messages. This can be different for each CAN node and is stored in the slave in object 100Ch:00 (unit: milliseconds) live time factor: A multiplier for the guard time; this is stored in the CAN slave in object 100Dh:00 and can be different for each slave on the CAN bus. possible live time: The time produced by multiplying guard time and live time factor. The following conditions are checked during Nodeguarding: The NMT master must send the RTR request within the "possible live time". The slave must send the response to the RTR request within the "possible live time". The slave must respond with its NMT state. In addition, the "toggle bit" must be set correctly. Heartbeat If Heartbeat is activated, the slave sends its NMT state to the CAN bus unprompted and cyclically. You activate this service by setting the Producer Heartbeat Time time in object 1017h:00h to a value other than zero. The Producer Heartbeat Time is measured in milliseconds. The message sent by the slave has the form shown below: The slave must send the Heartbeat message within the Heartbeat Consumer Time. This time is known only to the master and is not stored in the controller. The slave can also monitor a Heartbeat from another producer (master or another slave). To do this, enter the Consumer Heartbeat Time and the node-ID of the producer in object 1016h. Errors that occur during this monitoring are reset if either the function is deactivated or the Heartbeat is again sent within the correct time.
CANopen services The CANopen stack offers the services listed in the following table; more detailed descriptions can be found in the respective chapters. Default CAN-ID Service Description in 000h Network Management (NMT) Section Network Management (NMT) 080h Synchronization Object Section Synchronization object (SYNC) 080h+Node-ID Emergency Section Emergency Object (EMCY) 180h+Node-ID TX Process Data Objects (PDO) Section Process Data Object (PDO) 200h+Node-ID RX Process Data Objects (PDO) 280h+Node-ID TX Process Data Objects (PDO) 300h+Node-ID RX Process Data Objects (PDO) 380h+Node-ID TX Process Data Objects (PDO) 400h+Node-ID RX Process Data Objects (PDO) 480h+Node-ID TX Process Data Objects (PDO) 500h+Node-ID RX Process Data Objects (PDO) 580h+Node-ID TX Service Data Objects (SDO) Section Service Data Object (SDO) 600h+Node-ID RX Service Data Objects (SDO) 700h+Node-ID BOOT-UP Protocol Section Boot-Up Protocol 700h+Node-ID Nodeguarding and Heartbeat Section Heartbeat and Nodeguarding The setting for the node-ID can be found in Position of the virtual rotary switch. Network Management (NMT) The network management 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-ID 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 "Initialization" 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. In object 1F80h, you can set whether the "Operational" state is automatically switched to afterwards, thereby allowing you to avoid sending an additional NMT command. Shown in the following table is an overview of the activity of the services in the respective states. Note that the Stopped state stops communication completely and only permits controller of the NMT state machine. Service Initializing Pre-Operational Operational Stopped PDO Active SDO Active Active SYNC Active Active EMCY Active Active BOOT-UP Active NMT Active Active Active The "Network Management" message has CAN-ID 0. A message is always two bytes long and has the following structure: Here, the <CMD> corresponds to one of the following bytes (see also the legend in the figure of the NMT state diagram): <CMD> Meaning 01h Switch to the "Operational" state 02h Switch to the "Stop" state 80h Switch to the "Pre-Operational" state 81h Reset Node 82h Reset Communication Completely restart the controller with the "Reset Node" command. Use the "Reset Communication" command to reset the CANopen settings and restart the communication. The value for <Node-ID> can be 00h; in this case, the NMT command applies for all devices on the CAN bus (broadcast). If a number not equal to zero is used, only the device with the corresponding node-ID is addressed. Example: If all devices on the CAN bus are to be switched to the "Stop" operating state, a broadcast with the "Switch to the Stop state" command can be used. The NMT message is structured as follows: 000 | 02 00 If only the device with node-ID 42 is to be completely restarted, the following CAN message is to be sent: 000 | 01 2A Synchronization object (SYNC) 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 usually 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 chapter 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. If the time of the window has elapsed, all devices must stop sending PDOs. The "synchronous window length" can be set in microseconds in object 1007h:00h. A typical CAN-SYNC operation is divided into four phases (see also the following figure): 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. The TX-PDOs are then sent by all slaves on the bus. Afterwards, the PDOs are sent by the CANopen master. After the "synchronous window length" time has elapsed, no further PDOs are permitted. SDO messages can be exchanged at the latest when the "synchronous window" is closed again. If the Sync Producer supports a Sync Counter, the sync message receives an additional 1-byte numerical value. This counter is increased by the value "1" per sent sync message and is reset each time the value 1019h Synchronous Counter Overflow Value is reached. For each TX-PDO, a start value of the Sync Counter can be defined in subindex 06h of the corresponding communication parameter (e.g., in 1800h:06h) beginning with which the slave is to respond to the sync for the first time and send the PDO. The function is not activated until a value greater than 1 is set in 1019h. Emergency Object (EMCY) 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 80h+Node-ID. The emergency message is structured as follows: A total of three error codes are transferred here: the "Emergency Error Code" (<EMCY Error Code>) the content of the "Error Register" object (1001h), E-REG the "Error Number" (E-Number) Error handling A module for error handling processes all errors that occur internally. Each error is classified into an error class. Each error that occurs is handled as follows: The bit that belongs to the error in the "Error Register" object (1001h) is set. Three pieces of information are then written together in the "Pre-defined Error Field" object (1003h:01): The Emergency Error Code The Error Register The manufacturer-specific error code If no further errors are pending, the following message is sent: 80 + Node-ID | 00 00 E-REG E-Number 00 00 00 00 In object 1029h, you can configure whether and how the controller is to change its NMT state in case of an error. Service Data Object (SDO) A "Service Data Object" permits read or write access of the object dictionary. In the following, the owner of the object dictionary is referred to as the "server"; the CAN node – which wants to request or write the data – is referred to as the "client". An "upload" refers to the reading of a value of an object from the object dictionary; a "download" refers to the writing of a value in the object dictionary. In addition, the following abbreviations are used in the diagrams: <IDX>: Index of the object that is to be read or written in the object dictionary; the LSB of the index is in byte 1 here. Example: The statusword of the controller has index 6041h; byte 1 is then written with 41h and byte 2 with 60h. With Expedited Transfer, the SDO answer contains the same index as that of the request. <SUBIDX>: Subindex of the object in the object dictionary from 00h to FFh. With Expedited Transfer, the answer of the SDO message of the controller also contains the subindex of the request. Because CAN messages of type SDO contain a large amount of metadata, you should only use SDO messages to configure the controller. Should it be necessary to cyclically exchange data during running operation, use CANopen messages of type PDO (see subsection Process Data Object). The SDO transfers are divided into three types of access: "expedited transfer" for transferring objects with up to four bytes. "normal transfer" for transferring any number of bytes, whereby each CAN message is confirmed individually. "block transfer" is also for any number of bytes; here, a given block of CAN tickets is confirmed at once. An SDO message is sent to CAN-ID 600h + node-ID, the answer comes from CAN-ID 580h + node-ID. Expedited Transfer This method is used to write (download) or read (upload) values in objects of type (UN)SIGNED8, 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: 2Fh 2 byte data length: 2Bh 3 byte data length: 27h 4 byte data length: 23h 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 SDO error messages). Example: Set object 607Ah:00h (target position, SIGNED32) to value 3E8h (=1000d) of a controller with node-ID 3: 603 | 23 7A 60 00 E8 03 00 00 Where Byte 1 (23h): SDO expedited download, 4 bytes of data (SIGNED32) Bytes 2 and 3 (7Ah 60h): index of object is 607Ah Byte 4 (00h): subindex of object is 00h Bytes 5 to 8 (E8h 03h 00h 00h): value of object: 000003E8h If 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. The length of the data is encrypted in the <CMD> of the answer: 1 byte data length: 4Fh 2 byte data length: 4Bh 3 byte data length: 47h 4 byte data length: 43h The LSB of the data is again in byte 4 here. In case of an error, the reason for the error is also specified in the data (see list of SDO error messages in SDO error messages). Example: To read the "statusword" object (6041h:00) from the object dictionary, it suffices to send the following message (always 8 bytes): 603 | 40 41 60 00 00 00 00 00 The controller generally responds with the following message: 583 | 4B 41 60 00 40 02 00 00 Where Byte 1 (4Bh): SDO expedited upload, 2 bytes of data (UNSIGNED16) Bytes 2 and 3 (41h 60h): index of object is 6041h Byte 4 (00h): subindex of object is 00h Bytes 5 to 6 (40h 02h ): value of object: 0240h Bytes 7 to 8 (00h 2h h h): empty. An SDO message always consists of 8 bytes. Normal Transfer Unlike "expedited" CANopen transfer, "normal transfer" is not limited to maximum four bytes. With this type of transfer, the content of multiple messages is grouped together with respect to content; such a block of messages is referred to in the following as a "transfer". Each message within a transfer is confirmed individually here. Note: If your CANopen master does not support normal transfer, there is another way to access objects of data type String: each string can be read out character by character with an SDO upload to subindex 1 and the following subindicies. SDO upload Shown in the following figure is the procedure for an "SDO upload" (client requests that the content of an object be sent to it). The transfer is broken down into two phases: an initialization phase and a transfer phase. As with an "expedited transfer", the upload begins with the client sending an "Init SDO Update" to the server (see following figure). The answer for a "normal transfer" does not contain the quantity of bytes to be received encoded in the <CMD>. It is instead entered in the data range as can be seen in the following figure in the <DATA LENGTH> area. The initialization is thereby concluded; all that remains is the upload of the data. A data packet is requested with the following SDO request: Byte 0 with command <CMD> is structured as follows: The bit with designation t alternates with each request ("toggle bit"). It begins each transfer with 0, even if the previous transfer was aborted. The controller responds to the above message with the data, whereby the message is structured as follows: Byte 0 with <CMD> is structured as follows: The bits have the following meaning here: t (toggle bit) The bit alternates with each message sequence; it does not change within a sequence between "request" and "response". n (number of bytes) These three bits specify how many bytes contain no data. Example: If bits 2 and 1 are set to 0 and bit 3 is set to 1, then 011b = 03d bytes are not valid. This, in turn, means that byte 1 to byte 4 contain allowed values and byte 5 to byte 7 should be disregarded. c (more segments) If no further SDO segments are sent and this is the last segment, the bit is set to 1. Example: In this example, the "Manufacturer Software Version" object (100Ah) is to be read. The node-ID of the node in this example is 3. The corresponding SDO message sequence is listed in the following table. The string that is to be read out varies from controller to controller. COB-ID Data Description 603h 40 0A 10 00 00 00 00 00 Init Upload; Index: 100Ah; Subindex: 00 583h 41 0A 10 00 11 00 00 00 Init Upload; Size: indicated; transfer type: normal; Num of bytes: 17; Index: 100Ah; Subindex: 00 603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set 583h 00 46 49 52 2D 76 31 37 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: not set 603h 70 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: set 583h 10 34 38 2D 42 35 33 38 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: set 603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set 583h 09 36 36 32 00 00 00 00 Upload Segment Conf.; More segments: no (last segment); num of bytes: 3; Toggle bit: not set 46 49 52 2D 76 31 37 34 38 2D 42 35 33 38 36 36 32 This corresponds to string: "FIR-v1748-B538662" Aborting the SDO transfer Both the server and the client are authorized to abort the current transfer. To do this, an "Abort SDO Transfer" must be sent; this is depicted in the following. After receiving the message, the SDO transfer is considered ended; the service is not confirmed. A new SDO transfer must then be started from the very beginning. Transfer of the <ERROR CODE> is optional; the controller does not evaluate the code. SDO error messages In case of an error, an error number specifying the reason for the error is also sent in the data area. Error Code Description 05030000h toggle bit not changed: Valid only with "normal transfer" or "block transfer". The bit, which is to alternate after each transfer, did not change its state. 05040001h command specifier unknown: Byte 0 of the data block contains a command that is not allowed. 06010000h unsupported access: If "complete access" was requested via CAN over EtherCAT (CoE) (is not supported.) 06010002h read only entry: An attempt was made to write to a constant or read-only object. 06020000h object not existing: An attempt was made to access a non-existing object (index incorrect). 06040041h object cannot be pdo mapped: An attempt was made to map an object in the PDO for which that is not permissible. 06040042h mapped pdo exceed pdo: If the desired object were to be attached to the PDO mapping, the 8 bytes of the PDO mapping would be exceeded. 06070012h parameter length too long: An attempt was made to write to an object with too much data; for example, with <CMD>=23h (4 bytes) to an object of type Unsigned8, <CMD>=2Fh would be correct. 06070013h parameter length too short: At attempt was made to write to an object with too little data; for example, with <CMD>=2Fh (1 byte) to an object of type Unsigned32, <CMD>=23h would be correct. 06090011h subindex not existing: An attempt was made to access an invalid subindex of an object; the index, on the other hand, would exist. 06090031h value too great: Some objects are subject to restrictions in the size of the value; in this case, an attempt was made to write an excessively large value to the object. For example, the "Pre-defined error field: Number of errors" object for 1003h:00 may only be set to the value "0"; all other numerical values result in this error. 06090032h value too small: Some objects are subject to restrictions in the size of the value. In this case, an attempt was made to write a value that is too small to the object. 08000000h general error: General error that does not fit in any other category. 08000022h data cannot be read or stored in this state: The parameters of the PDOs may only be changed in the "Stopped" or "Pre-Operational" state. Write access of objects 1400h to 1407h, 1600h to 1607h, 1800h to 1807h and 1A00h to 1A07h is not permissible in the "Operational" state. Process Data Object (PDO) A message that only contains process data is referred to as a "Process Data Object" (PDO). The PDO is intended for data that need to be exchanged cyclically. The idea behind a PDO message is to remove all additional information (index, subindex and data length) from a CAN message and to only fill the CAN message with data. The source and target information for the PDO are stored separately in the so-called PDO mapping. PDOs can only be used if the NMT state machine is in the "Operational" state (see section Network Management (NMT)); the PDOs must be configured in the "Pre-Operational" NMT state. The controller supports a total of 8 independent PDO mappings; each corresponding PDO message can have a maximum of eight bytes (=64 bit) of user data. It is thereby possible to, for example, transfer two UNSIGNED32 values or one UNSIGNED32 and one UNSIGNED08; the message does not need to use all eight data bytes. The PDOs differ yet again in the configuration in the send and receive configuration. The receive configuration describes the processing for PDO messages that are sent, and the send configuration describes the PDO messages that are to be sent. RX configuration To configure an RX-PDO, you must take into account three object categories in the object dictionary: The objects that describe the functionality of the mapping. The objects that describe the content of the mapping. 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 1401h and so on. In the following, we refer to 140Nh. Here, the configuration affects the COB-ID of the PDO message and the transfer type. Objects 140Nh have only three subindices: Subindex 0 (max. subindex): Total number of subindices Subindex 1 (COB-ID): The COB-ID is stored here. For PDO mappings 1–4 (1600h–1603h), 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 1604h–1607h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table at the start of chapter CANopen services) as can the valid bit. The change of a COB-ID does not take effect until after the controller or communication is restarted (see Network Management (NMT)). Mapping COB-ID 1600h 200h + Node-ID 1601h 300h + Node-ID 1602h 400h + Node-ID 1603h 500h + Node-ID 1604h xxxh + Node-ID 1605h xxxh + Node-ID 1606h xxxh + Node-ID 1607h xxxh + Node-ID 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. 140Nh:02h Meaning 00h-F0h Synchronous: The data are buffered and not until the next SYNC message is received do they become valid and are they taken over into the object dictionary. F1h-FDh Reserved FEh, FFh Asynchronous: The data become valid when the PDO message is received and are taken over into the object dictionary. 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 belong together. Thus, 1600h with all subindices describes the first mapping, 1601h the second RX-PDO mapping, etc. Subindex 00h specifies how many objects are in a mapping. It simultaneously specifies how many of the subindices are valid. If object 1600h:00h 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 1600h:03h and 1600h:04h is, therefore, not active (shown in gray). Each subindex from 1600h:01h to 1600h:0Fh 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 6040h:00h. In hexadecimal notation, the content of 1600h:01h then consists of<Index><Subindex><Bit length>or 60400010. The second mapping (1600h:02h) contains the entry 607A0020. Thus, it maps the following four bytes (=20hBit) in object 607Ah:00h Dummy objects You can configure RX-PDOs so that more than one node can respond. In this case, it may be desirable for only part of the data contained in the PDO to be evaluated in one of the devices. For data not used locally, you can include a dummy object of one of the supported data types in the mapping of the PDO: Index Data type 0002h INTEGER8 0003h INTEGER16 0004h INTEGER32 0005h UNSIGNED08 0006h UNSIGNED16 0007h UNSIGNED32 TX configuration To configure a TX-PDO, you must take into account three object categories in the object dictionary: The objects that describe the functionality of the mapping. The objects that describe the content of the mapping. 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 1800h. The second mapping is configured in 1801h and so on. In the following, we refer to 180Nh. Here, the configuration affects the COB-ID of the PDO message and the transfer type. Objects 180Nh 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 (1A00h–1A03h), 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 1A04h–1A07h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table at the start of chapter CANopen services) 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)). Mapping COB-ID 1A00h 180h + Node-ID 1A01h 280h + Node-ID 1A02h 380h + Node-ID 1A03h 480h + Node-ID 1A04h xxxh + Node-ID 1A05h xxxh + Node-ID 1A06h xxxh + Node-ID 1A07h xxxh + Node-ID 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 180Nh:5). If 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. 180Nh:02h Meaning 0 Synchronous (acyclic): The data are copied to the TX-PDO upon arrival of the SYNC but are not sent until the Event. 01h-F0h Synchronous (cyclic): The data are copied upon arrival of the nth SNCY message and are sent immediately thereafter (n corresponds to the number 1 to 240, transmission type "1" sends the new data on each SYNC). F1h-FBh Reserved FCh RTR-Only (synchronous): The data are copied upon arrival of each SYNC message but are sent only upon request with an RTR message. FDh RTR-Only (event-driven): The data are copied to the TX-PDO message upon receipt of an RTR message and sent immediately thereafter. FEh, FFh The data are copied upon arrival of the Event and sent immediately. Subindex 3 (inhibit time): This subindex contains a time lock in 100 µs steps (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 (in ms) 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 slave is to initially respond to the sync and send the PDO. Not globally activated until a value greater than 1 is set in 1019h Synchronous Counter Overflow Value. Content of a 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 belong together. Thus, 1A00h with all subindices describes the first mapping, 1A01h the second TX-PDO mapping, etc. Subindex 00 specifies how many objects are in a mapping. It simultaneously specifies how many of the subindices are valid. If object 1A00h:00h is set to "0", TX mapping is thereby completely switched off. In the following example, two objects are thereby mapped in entries 1A00h:01h – 1A00h:02h. The objects in entries 1A00h:03h – 1A00h:04h are, thus, not mapped (shown in gray). Each subindex from 1A00h:01h to 1A00h:0Fh 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 6041h:00h. In hexadecimal notation, the content of 1A00h:01h then consists of <Index><Subindex><Bit Length>, or 60410010. The second mapping (1A00h:02h) contains the entry 60640020. Thus, it maps the following four bytes (corresponds to 32 bits) from object 6064h:00h in the TX-PDO message. Presetting The following configuration is preset: RX-PDO 1. Mapping (CAN-ID: 200h + Node-ID): 6040h:00h (controlword) 6060h:00h (mode of operation) 3202h:00h (motor drive submode select) 2. Mapping (CAN-ID: 300h + Node-ID): 607Ah:00h (target position) 6081h:00h (profile velocity) 3. Mapping (CAN-ID: 400h + Node-ID): object 6042h:00h (vl target velocity) 4. Mapping (CAN-ID: 500h + Node-ID): object 60FEh:01h (digital outputs) TX-PDO 1. Mapping (CAN-ID: 180h + Node-ID): 6041h:00h (statusword) 6061h:00h (Modes Of Operation Display) 2. Mapping (CAN-ID: 280h + Node-ID): 6064h:00h (Position actual value) 3. Mapping (CAN-ID: 380h + Node-ID): 6044h:00h (vl velocity actual value) 4. Mapping (CAN-ID: 480h + Node-ID): object 60FDh:00h (digital inputs) Changing PDO mapping You change the PDO mapping in the "Pre-operational" NMT state as follows: Deactivate the PDO by setting the Valid Bit (bit 31) of subindex 01h of the corresponding communication parameter (e.g., 1400h:01h) to "1". Deactivate the mapping by setting subindex 00h of the corresponding mapping parameter (e.g., 1600h:00h) to "0". Change the mapping in the desired subindices (e.g., 1600h:01h). Activate the mapping by writing the number of objects that are to be mapped in subindex 00h of the corresponding mapping parameter (e.g., 1600h:00h). Activate the PDO by setting bit 31 of subindex 01h of the corresponding communication parameter (e.g., 1400h:01h) to "0". Store the configuration by writing the value "65766173h" in 1010h:03h. Boot-Up Protocol If the CAN slave reaches the "Pre-Operational" NMT state (see following figure), the following message is sent to signal operational readiness. This service is unconfirmed; there is no response. Note: The boot loader sends its own boot-up message. This can be suppressed, see object 2007h:00 Heartbeat and Nodeguarding With the "Heartbeat" and "Nodeguarding" services (often also referred to as "Lifeguarding"), switched-off or hung devices on the CAN bus can be found. For this purpose, the NMT master cyclically requests a message with the current NMT state of the slave (Nodeguarding). The alternative is that each slave sends a message unprompted and cyclically (Heartbeat). A combination of Nodeguarding and Heartbeat is not permissible. Furthermore, it is recommended that Heartbeat be given preference over Nodeguarding, as Nodeguarding results in a higher load on the CAN bus. Nodeguarding This service is based on the fact that the NMT master sends an RTR message with CAN-ID 700h + 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): guard time: The time between two RTR messages. This can be different for each CAN node and is stored in the slave in object 100Ch:00 (unit: milliseconds) live time factor: A multiplier for the guard time; this is stored in the CAN slave in object 100Dh:00 and can be different for each slave on the CAN bus. possible live time: The time produced by multiplying guard time and live time factor. The following conditions are checked during Nodeguarding: The NMT master must send the RTR request within the "possible live time". The slave must send the response to the RTR request within the "possible live time". The slave must respond with its NMT state. In addition, the "toggle bit" must be set correctly. Heartbeat If Heartbeat is activated, the slave sends its NMT state to the CAN bus unprompted and cyclically. You activate this service by setting the Producer Heartbeat Time time in object 1017h:00h to a value other than zero. The Producer Heartbeat Time is measured in milliseconds. The message sent by the slave has the form shown below: The slave must send the Heartbeat message within the Heartbeat Consumer Time. This time is known only to the master and is not stored in the controller. The slave can also monitor a Heartbeat from another producer (master or another slave). To do this, enter the Consumer Heartbeat Time and the node-ID of the producer in object 1016h. Errors that occur during this monitoring are reset if either the function is deactivated or the Heartbeat is again sent within the correct time.
Network Management (NMT) The network management 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-ID 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 "Initialization" 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. In object 1F80h, you can set whether the "Operational" state is automatically switched to afterwards, thereby allowing you to avoid sending an additional NMT command. Shown in the following table is an overview of the activity of the services in the respective states. Note that the Stopped state stops communication completely and only permits controller of the NMT state machine. Service Initializing Pre-Operational Operational Stopped PDO Active SDO Active Active SYNC Active Active EMCY Active Active BOOT-UP Active NMT Active Active Active The "Network Management" message has CAN-ID 0. A message is always two bytes long and has the following structure: Here, the <CMD> corresponds to one of the following bytes (see also the legend in the figure of the NMT state diagram): <CMD> Meaning 01h Switch to the "Operational" state 02h Switch to the "Stop" state 80h Switch to the "Pre-Operational" state 81h Reset Node 82h Reset Communication Completely restart the controller with the "Reset Node" command. Use the "Reset Communication" command to reset the CANopen settings and restart the communication. The value for <Node-ID> can be 00h; in this case, the NMT command applies for all devices on the CAN bus (broadcast). If a number not equal to zero is used, only the device with the corresponding node-ID is addressed. Example: If all devices on the CAN bus are to be switched to the "Stop" operating state, a broadcast with the "Switch to the Stop state" command can be used. The NMT message is structured as follows: 000 | 02 00 If only the device with node-ID 42 is to be completely restarted, the following CAN message is to be sent: 000 | 01 2A
Synchronization object (SYNC) 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 usually 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 chapter 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. If the time of the window has elapsed, all devices must stop sending PDOs. The "synchronous window length" can be set in microseconds in object 1007h:00h. A typical CAN-SYNC operation is divided into four phases (see also the following figure): 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. The TX-PDOs are then sent by all slaves on the bus. Afterwards, the PDOs are sent by the CANopen master. After the "synchronous window length" time has elapsed, no further PDOs are permitted. SDO messages can be exchanged at the latest when the "synchronous window" is closed again. If the Sync Producer supports a Sync Counter, the sync message receives an additional 1-byte numerical value. This counter is increased by the value "1" per sent sync message and is reset each time the value 1019h Synchronous Counter Overflow Value is reached. For each TX-PDO, a start value of the Sync Counter can be defined in subindex 06h of the corresponding communication parameter (e.g., in 1800h:06h) beginning with which the slave is to respond to the sync for the first time and send the PDO. The function is not activated until a value greater than 1 is set in 1019h.
Emergency Object (EMCY) 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 80h+Node-ID. The emergency message is structured as follows: A total of three error codes are transferred here: the "Emergency Error Code" (<EMCY Error Code>) the content of the "Error Register" object (1001h), E-REG the "Error Number" (E-Number) Error handling A module for error handling processes all errors that occur internally. Each error is classified into an error class. Each error that occurs is handled as follows: The bit that belongs to the error in the "Error Register" object (1001h) is set. Three pieces of information are then written together in the "Pre-defined Error Field" object (1003h:01): The Emergency Error Code The Error Register The manufacturer-specific error code If no further errors are pending, the following message is sent: 80 + Node-ID | 00 00 E-REG E-Number 00 00 00 00 In object 1029h, you can configure whether and how the controller is to change its NMT state in case of an error.
Error handling A module for error handling processes all errors that occur internally. Each error is classified into an error class. Each error that occurs is handled as follows: The bit that belongs to the error in the "Error Register" object (1001h) is set. Three pieces of information are then written together in the "Pre-defined Error Field" object (1003h:01): The Emergency Error Code The Error Register The manufacturer-specific error code If no further errors are pending, the following message is sent: 80 + Node-ID | 00 00 E-REG E-Number 00 00 00 00 In object 1029h, you can configure whether and how the controller is to change its NMT state in case of an error.
Service Data Object (SDO) A "Service Data Object" permits read or write access of the object dictionary. In the following, the owner of the object dictionary is referred to as the "server"; the CAN node – which wants to request or write the data – is referred to as the "client". An "upload" refers to the reading of a value of an object from the object dictionary; a "download" refers to the writing of a value in the object dictionary. In addition, the following abbreviations are used in the diagrams: <IDX>: Index of the object that is to be read or written in the object dictionary; the LSB of the index is in byte 1 here. Example: The statusword of the controller has index 6041h; byte 1 is then written with 41h and byte 2 with 60h. With Expedited Transfer, the SDO answer contains the same index as that of the request. <SUBIDX>: Subindex of the object in the object dictionary from 00h to FFh. With Expedited Transfer, the answer of the SDO message of the controller also contains the subindex of the request. Because CAN messages of type SDO contain a large amount of metadata, you should only use SDO messages to configure the controller. Should it be necessary to cyclically exchange data during running operation, use CANopen messages of type PDO (see subsection Process Data Object). The SDO transfers are divided into three types of access: "expedited transfer" for transferring objects with up to four bytes. "normal transfer" for transferring any number of bytes, whereby each CAN message is confirmed individually. "block transfer" is also for any number of bytes; here, a given block of CAN tickets is confirmed at once. An SDO message is sent to CAN-ID 600h + node-ID, the answer comes from CAN-ID 580h + node-ID. Expedited Transfer This method is used to write (download) or read (upload) values in objects of type (UN)SIGNED8, 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: 2Fh 2 byte data length: 2Bh 3 byte data length: 27h 4 byte data length: 23h 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 SDO error messages). Example: Set object 607Ah:00h (target position, SIGNED32) to value 3E8h (=1000d) of a controller with node-ID 3: 603 | 23 7A 60 00 E8 03 00 00 Where Byte 1 (23h): SDO expedited download, 4 bytes of data (SIGNED32) Bytes 2 and 3 (7Ah 60h): index of object is 607Ah Byte 4 (00h): subindex of object is 00h Bytes 5 to 8 (E8h 03h 00h 00h): value of object: 000003E8h If 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. The length of the data is encrypted in the <CMD> of the answer: 1 byte data length: 4Fh 2 byte data length: 4Bh 3 byte data length: 47h 4 byte data length: 43h The LSB of the data is again in byte 4 here. In case of an error, the reason for the error is also specified in the data (see list of SDO error messages in SDO error messages). Example: To read the "statusword" object (6041h:00) from the object dictionary, it suffices to send the following message (always 8 bytes): 603 | 40 41 60 00 00 00 00 00 The controller generally responds with the following message: 583 | 4B 41 60 00 40 02 00 00 Where Byte 1 (4Bh): SDO expedited upload, 2 bytes of data (UNSIGNED16) Bytes 2 and 3 (41h 60h): index of object is 6041h Byte 4 (00h): subindex of object is 00h Bytes 5 to 6 (40h 02h ): value of object: 0240h Bytes 7 to 8 (00h 2h h h): empty. An SDO message always consists of 8 bytes. Normal Transfer Unlike "expedited" CANopen transfer, "normal transfer" is not limited to maximum four bytes. With this type of transfer, the content of multiple messages is grouped together with respect to content; such a block of messages is referred to in the following as a "transfer". Each message within a transfer is confirmed individually here. Note: If your CANopen master does not support normal transfer, there is another way to access objects of data type String: each string can be read out character by character with an SDO upload to subindex 1 and the following subindicies. SDO upload Shown in the following figure is the procedure for an "SDO upload" (client requests that the content of an object be sent to it). The transfer is broken down into two phases: an initialization phase and a transfer phase. As with an "expedited transfer", the upload begins with the client sending an "Init SDO Update" to the server (see following figure). The answer for a "normal transfer" does not contain the quantity of bytes to be received encoded in the <CMD>. It is instead entered in the data range as can be seen in the following figure in the <DATA LENGTH> area. The initialization is thereby concluded; all that remains is the upload of the data. A data packet is requested with the following SDO request: Byte 0 with command <CMD> is structured as follows: The bit with designation t alternates with each request ("toggle bit"). It begins each transfer with 0, even if the previous transfer was aborted. The controller responds to the above message with the data, whereby the message is structured as follows: Byte 0 with <CMD> is structured as follows: The bits have the following meaning here: t (toggle bit) The bit alternates with each message sequence; it does not change within a sequence between "request" and "response". n (number of bytes) These three bits specify how many bytes contain no data. Example: If bits 2 and 1 are set to 0 and bit 3 is set to 1, then 011b = 03d bytes are not valid. This, in turn, means that byte 1 to byte 4 contain allowed values and byte 5 to byte 7 should be disregarded. c (more segments) If no further SDO segments are sent and this is the last segment, the bit is set to 1. Example: In this example, the "Manufacturer Software Version" object (100Ah) is to be read. The node-ID of the node in this example is 3. The corresponding SDO message sequence is listed in the following table. The string that is to be read out varies from controller to controller. COB-ID Data Description 603h 40 0A 10 00 00 00 00 00 Init Upload; Index: 100Ah; Subindex: 00 583h 41 0A 10 00 11 00 00 00 Init Upload; Size: indicated; transfer type: normal; Num of bytes: 17; Index: 100Ah; Subindex: 00 603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set 583h 00 46 49 52 2D 76 31 37 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: not set 603h 70 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: set 583h 10 34 38 2D 42 35 33 38 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: set 603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set 583h 09 36 36 32 00 00 00 00 Upload Segment Conf.; More segments: no (last segment); num of bytes: 3; Toggle bit: not set 46 49 52 2D 76 31 37 34 38 2D 42 35 33 38 36 36 32 This corresponds to string: "FIR-v1748-B538662" Aborting the SDO transfer Both the server and the client are authorized to abort the current transfer. To do this, an "Abort SDO Transfer" must be sent; this is depicted in the following. After receiving the message, the SDO transfer is considered ended; the service is not confirmed. A new SDO transfer must then be started from the very beginning. Transfer of the <ERROR CODE> is optional; the controller does not evaluate the code. SDO error messages In case of an error, an error number specifying the reason for the error is also sent in the data area. Error Code Description 05030000h toggle bit not changed: Valid only with "normal transfer" or "block transfer". The bit, which is to alternate after each transfer, did not change its state. 05040001h command specifier unknown: Byte 0 of the data block contains a command that is not allowed. 06010000h unsupported access: If "complete access" was requested via CAN over EtherCAT (CoE) (is not supported.) 06010002h read only entry: An attempt was made to write to a constant or read-only object. 06020000h object not existing: An attempt was made to access a non-existing object (index incorrect). 06040041h object cannot be pdo mapped: An attempt was made to map an object in the PDO for which that is not permissible. 06040042h mapped pdo exceed pdo: If the desired object were to be attached to the PDO mapping, the 8 bytes of the PDO mapping would be exceeded. 06070012h parameter length too long: An attempt was made to write to an object with too much data; for example, with <CMD>=23h (4 bytes) to an object of type Unsigned8, <CMD>=2Fh would be correct. 06070013h parameter length too short: At attempt was made to write to an object with too little data; for example, with <CMD>=2Fh (1 byte) to an object of type Unsigned32, <CMD>=23h would be correct. 06090011h subindex not existing: An attempt was made to access an invalid subindex of an object; the index, on the other hand, would exist. 06090031h value too great: Some objects are subject to restrictions in the size of the value; in this case, an attempt was made to write an excessively large value to the object. For example, the "Pre-defined error field: Number of errors" object for 1003h:00 may only be set to the value "0"; all other numerical values result in this error. 06090032h value too small: Some objects are subject to restrictions in the size of the value. In this case, an attempt was made to write a value that is too small to the object. 08000000h general error: General error that does not fit in any other category. 08000022h data cannot be read or stored in this state: The parameters of the PDOs may only be changed in the "Stopped" or "Pre-Operational" state. Write access of objects 1400h to 1407h, 1600h to 1607h, 1800h to 1807h and 1A00h to 1A07h is not permissible in the "Operational" state.
Expedited Transfer This method is used to write (download) or read (upload) values in objects of type (UN)SIGNED8, 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: 2Fh 2 byte data length: 2Bh 3 byte data length: 27h 4 byte data length: 23h 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 SDO error messages). Example: Set object 607Ah:00h (target position, SIGNED32) to value 3E8h (=1000d) of a controller with node-ID 3: 603 | 23 7A 60 00 E8 03 00 00 Where Byte 1 (23h): SDO expedited download, 4 bytes of data (SIGNED32) Bytes 2 and 3 (7Ah 60h): index of object is 607Ah Byte 4 (00h): subindex of object is 00h Bytes 5 to 8 (E8h 03h 00h 00h): value of object: 000003E8h If 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. The length of the data is encrypted in the <CMD> of the answer: 1 byte data length: 4Fh 2 byte data length: 4Bh 3 byte data length: 47h 4 byte data length: 43h The LSB of the data is again in byte 4 here. In case of an error, the reason for the error is also specified in the data (see list of SDO error messages in SDO error messages). Example: To read the "statusword" object (6041h:00) from the object dictionary, it suffices to send the following message (always 8 bytes): 603 | 40 41 60 00 00 00 00 00 The controller generally responds with the following message: 583 | 4B 41 60 00 40 02 00 00 Where Byte 1 (4Bh): SDO expedited upload, 2 bytes of data (UNSIGNED16) Bytes 2 and 3 (41h 60h): index of object is 6041h Byte 4 (00h): subindex of object is 00h Bytes 5 to 6 (40h 02h ): value of object: 0240h Bytes 7 to 8 (00h 2h h h): empty. An SDO message always consists of 8 bytes.
Normal Transfer Unlike "expedited" CANopen transfer, "normal transfer" is not limited to maximum four bytes. With this type of transfer, the content of multiple messages is grouped together with respect to content; such a block of messages is referred to in the following as a "transfer". Each message within a transfer is confirmed individually here. Note: If your CANopen master does not support normal transfer, there is another way to access objects of data type String: each string can be read out character by character with an SDO upload to subindex 1 and the following subindicies. SDO upload Shown in the following figure is the procedure for an "SDO upload" (client requests that the content of an object be sent to it). The transfer is broken down into two phases: an initialization phase and a transfer phase. As with an "expedited transfer", the upload begins with the client sending an "Init SDO Update" to the server (see following figure). The answer for a "normal transfer" does not contain the quantity of bytes to be received encoded in the <CMD>. It is instead entered in the data range as can be seen in the following figure in the <DATA LENGTH> area. The initialization is thereby concluded; all that remains is the upload of the data. A data packet is requested with the following SDO request: Byte 0 with command <CMD> is structured as follows: The bit with designation t alternates with each request ("toggle bit"). It begins each transfer with 0, even if the previous transfer was aborted. The controller responds to the above message with the data, whereby the message is structured as follows: Byte 0 with <CMD> is structured as follows: The bits have the following meaning here: t (toggle bit) The bit alternates with each message sequence; it does not change within a sequence between "request" and "response". n (number of bytes) These three bits specify how many bytes contain no data. Example: If bits 2 and 1 are set to 0 and bit 3 is set to 1, then 011b = 03d bytes are not valid. This, in turn, means that byte 1 to byte 4 contain allowed values and byte 5 to byte 7 should be disregarded. c (more segments) If no further SDO segments are sent and this is the last segment, the bit is set to 1. Example: In this example, the "Manufacturer Software Version" object (100Ah) is to be read. The node-ID of the node in this example is 3. The corresponding SDO message sequence is listed in the following table. The string that is to be read out varies from controller to controller. COB-ID Data Description 603h 40 0A 10 00 00 00 00 00 Init Upload; Index: 100Ah; Subindex: 00 583h 41 0A 10 00 11 00 00 00 Init Upload; Size: indicated; transfer type: normal; Num of bytes: 17; Index: 100Ah; Subindex: 00 603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set 583h 00 46 49 52 2D 76 31 37 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: not set 603h 70 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: set 583h 10 34 38 2D 42 35 33 38 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: set 603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set 583h 09 36 36 32 00 00 00 00 Upload Segment Conf.; More segments: no (last segment); num of bytes: 3; Toggle bit: not set 46 49 52 2D 76 31 37 34 38 2D 42 35 33 38 36 36 32 This corresponds to string: "FIR-v1748-B538662" Aborting the SDO transfer Both the server and the client are authorized to abort the current transfer. To do this, an "Abort SDO Transfer" must be sent; this is depicted in the following. After receiving the message, the SDO transfer is considered ended; the service is not confirmed. A new SDO transfer must then be started from the very beginning. Transfer of the <ERROR CODE> is optional; the controller does not evaluate the code.
SDO error messages In case of an error, an error number specifying the reason for the error is also sent in the data area. Error Code Description 05030000h toggle bit not changed: Valid only with "normal transfer" or "block transfer". The bit, which is to alternate after each transfer, did not change its state. 05040001h command specifier unknown: Byte 0 of the data block contains a command that is not allowed. 06010000h unsupported access: If "complete access" was requested via CAN over EtherCAT (CoE) (is not supported.) 06010002h read only entry: An attempt was made to write to a constant or read-only object. 06020000h object not existing: An attempt was made to access a non-existing object (index incorrect). 06040041h object cannot be pdo mapped: An attempt was made to map an object in the PDO for which that is not permissible. 06040042h mapped pdo exceed pdo: If the desired object were to be attached to the PDO mapping, the 8 bytes of the PDO mapping would be exceeded. 06070012h parameter length too long: An attempt was made to write to an object with too much data; for example, with <CMD>=23h (4 bytes) to an object of type Unsigned8, <CMD>=2Fh would be correct. 06070013h parameter length too short: At attempt was made to write to an object with too little data; for example, with <CMD>=2Fh (1 byte) to an object of type Unsigned32, <CMD>=23h would be correct. 06090011h subindex not existing: An attempt was made to access an invalid subindex of an object; the index, on the other hand, would exist. 06090031h value too great: Some objects are subject to restrictions in the size of the value; in this case, an attempt was made to write an excessively large value to the object. For example, the "Pre-defined error field: Number of errors" object for 1003h:00 may only be set to the value "0"; all other numerical values result in this error. 06090032h value too small: Some objects are subject to restrictions in the size of the value. In this case, an attempt was made to write a value that is too small to the object. 08000000h general error: General error that does not fit in any other category. 08000022h data cannot be read or stored in this state: The parameters of the PDOs may only be changed in the "Stopped" or "Pre-Operational" state. Write access of objects 1400h to 1407h, 1600h to 1607h, 1800h to 1807h and 1A00h to 1A07h is not permissible in the "Operational" state.
Process Data Object (PDO) A message that only contains process data is referred to as a "Process Data Object" (PDO). The PDO is intended for data that need to be exchanged cyclically. The idea behind a PDO message is to remove all additional information (index, subindex and data length) from a CAN message and to only fill the CAN message with data. The source and target information for the PDO are stored separately in the so-called PDO mapping. PDOs can only be used if the NMT state machine is in the "Operational" state (see section Network Management (NMT)); the PDOs must be configured in the "Pre-Operational" NMT state. The controller supports a total of 8 independent PDO mappings; each corresponding PDO message can have a maximum of eight bytes (=64 bit) of user data. It is thereby possible to, for example, transfer two UNSIGNED32 values or one UNSIGNED32 and one UNSIGNED08; the message does not need to use all eight data bytes. The PDOs differ yet again in the configuration in the send and receive configuration. The receive configuration describes the processing for PDO messages that are sent, and the send configuration describes the PDO messages that are to be sent. RX configuration To configure an RX-PDO, you must take into account three object categories in the object dictionary: The objects that describe the functionality of the mapping. The objects that describe the content of the mapping. 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 1401h and so on. In the following, we refer to 140Nh. Here, the configuration affects the COB-ID of the PDO message and the transfer type. Objects 140Nh have only three subindices: Subindex 0 (max. subindex): Total number of subindices Subindex 1 (COB-ID): The COB-ID is stored here. For PDO mappings 1–4 (1600h–1603h), 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 1604h–1607h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table at the start of chapter CANopen services) as can the valid bit. The change of a COB-ID does not take effect until after the controller or communication is restarted (see Network Management (NMT)). Mapping COB-ID 1600h 200h + Node-ID 1601h 300h + Node-ID 1602h 400h + Node-ID 1603h 500h + Node-ID 1604h xxxh + Node-ID 1605h xxxh + Node-ID 1606h xxxh + Node-ID 1607h xxxh + Node-ID 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. 140Nh:02h Meaning 00h-F0h Synchronous: The data are buffered and not until the next SYNC message is received do they become valid and are they taken over into the object dictionary. F1h-FDh Reserved FEh, FFh Asynchronous: The data become valid when the PDO message is received and are taken over into the object dictionary. 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 belong together. Thus, 1600h with all subindices describes the first mapping, 1601h the second RX-PDO mapping, etc. Subindex 00h specifies how many objects are in a mapping. It simultaneously specifies how many of the subindices are valid. If object 1600h:00h 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 1600h:03h and 1600h:04h is, therefore, not active (shown in gray). Each subindex from 1600h:01h to 1600h:0Fh 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 6040h:00h. In hexadecimal notation, the content of 1600h:01h then consists of<Index><Subindex><Bit length>or 60400010. The second mapping (1600h:02h) contains the entry 607A0020. Thus, it maps the following four bytes (=20hBit) in object 607Ah:00h Dummy objects You can configure RX-PDOs so that more than one node can respond. In this case, it may be desirable for only part of the data contained in the PDO to be evaluated in one of the devices. For data not used locally, you can include a dummy object of one of the supported data types in the mapping of the PDO: Index Data type 0002h INTEGER8 0003h INTEGER16 0004h INTEGER32 0005h UNSIGNED08 0006h UNSIGNED16 0007h UNSIGNED32 TX configuration To configure a TX-PDO, you must take into account three object categories in the object dictionary: The objects that describe the functionality of the mapping. The objects that describe the content of the mapping. 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 1800h. The second mapping is configured in 1801h and so on. In the following, we refer to 180Nh. Here, the configuration affects the COB-ID of the PDO message and the transfer type. Objects 180Nh 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 (1A00h–1A03h), 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 1A04h–1A07h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table at the start of chapter CANopen services) 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)). Mapping COB-ID 1A00h 180h + Node-ID 1A01h 280h + Node-ID 1A02h 380h + Node-ID 1A03h 480h + Node-ID 1A04h xxxh + Node-ID 1A05h xxxh + Node-ID 1A06h xxxh + Node-ID 1A07h xxxh + Node-ID 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 180Nh:5). If 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. 180Nh:02h Meaning 0 Synchronous (acyclic): The data are copied to the TX-PDO upon arrival of the SYNC but are not sent until the Event. 01h-F0h Synchronous (cyclic): The data are copied upon arrival of the nth SNCY message and are sent immediately thereafter (n corresponds to the number 1 to 240, transmission type "1" sends the new data on each SYNC). F1h-FBh Reserved FCh RTR-Only (synchronous): The data are copied upon arrival of each SYNC message but are sent only upon request with an RTR message. FDh RTR-Only (event-driven): The data are copied to the TX-PDO message upon receipt of an RTR message and sent immediately thereafter. FEh, FFh The data are copied upon arrival of the Event and sent immediately. Subindex 3 (inhibit time): This subindex contains a time lock in 100 µs steps (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 (in ms) 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 slave is to initially respond to the sync and send the PDO. Not globally activated until a value greater than 1 is set in 1019h Synchronous Counter Overflow Value. Content of a 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 belong together. Thus, 1A00h with all subindices describes the first mapping, 1A01h the second TX-PDO mapping, etc. Subindex 00 specifies how many objects are in a mapping. It simultaneously specifies how many of the subindices are valid. If object 1A00h:00h is set to "0", TX mapping is thereby completely switched off. In the following example, two objects are thereby mapped in entries 1A00h:01h – 1A00h:02h. The objects in entries 1A00h:03h – 1A00h:04h are, thus, not mapped (shown in gray). Each subindex from 1A00h:01h to 1A00h:0Fh 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 6041h:00h. In hexadecimal notation, the content of 1A00h:01h then consists of <Index><Subindex><Bit Length>, or 60410010. The second mapping (1A00h:02h) contains the entry 60640020. Thus, it maps the following four bytes (corresponds to 32 bits) from object 6064h:00h in the TX-PDO message. Presetting The following configuration is preset: RX-PDO 1. Mapping (CAN-ID: 200h + Node-ID): 6040h:00h (controlword) 6060h:00h (mode of operation) 3202h:00h (motor drive submode select) 2. Mapping (CAN-ID: 300h + Node-ID): 607Ah:00h (target position) 6081h:00h (profile velocity) 3. Mapping (CAN-ID: 400h + Node-ID): object 6042h:00h (vl target velocity) 4. Mapping (CAN-ID: 500h + Node-ID): object 60FEh:01h (digital outputs) TX-PDO 1. Mapping (CAN-ID: 180h + Node-ID): 6041h:00h (statusword) 6061h:00h (Modes Of Operation Display) 2. Mapping (CAN-ID: 280h + Node-ID): 6064h:00h (Position actual value) 3. Mapping (CAN-ID: 380h + Node-ID): 6044h:00h (vl velocity actual value) 4. Mapping (CAN-ID: 480h + Node-ID): object 60FDh:00h (digital inputs) Changing PDO mapping You change the PDO mapping in the "Pre-operational" NMT state as follows: Deactivate the PDO by setting the Valid Bit (bit 31) of subindex 01h of the corresponding communication parameter (e.g., 1400h:01h) to "1". Deactivate the mapping by setting subindex 00h of the corresponding mapping parameter (e.g., 1600h:00h) to "0". Change the mapping in the desired subindices (e.g., 1600h:01h). Activate the mapping by writing the number of objects that are to be mapped in subindex 00h of the corresponding mapping parameter (e.g., 1600h:00h). Activate the PDO by setting bit 31 of subindex 01h of the corresponding communication parameter (e.g., 1400h:01h) to "0". Store the configuration by writing the value "65766173h" in 1010h:03h.
RX configuration To configure an RX-PDO, you must take into account three object categories in the object dictionary: The objects that describe the functionality of the mapping. The objects that describe the content of the mapping. 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 1401h and so on. In the following, we refer to 140Nh. Here, the configuration affects the COB-ID of the PDO message and the transfer type. Objects 140Nh have only three subindices: Subindex 0 (max. subindex): Total number of subindices Subindex 1 (COB-ID): The COB-ID is stored here. For PDO mappings 1–4 (1600h–1603h), 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 1604h–1607h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table at the start of chapter CANopen services) as can the valid bit. The change of a COB-ID does not take effect until after the controller or communication is restarted (see Network Management (NMT)). Mapping COB-ID 1600h 200h + Node-ID 1601h 300h + Node-ID 1602h 400h + Node-ID 1603h 500h + Node-ID 1604h xxxh + Node-ID 1605h xxxh + Node-ID 1606h xxxh + Node-ID 1607h xxxh + Node-ID 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. 140Nh:02h Meaning 00h-F0h Synchronous: The data are buffered and not until the next SYNC message is received do they become valid and are they taken over into the object dictionary. F1h-FDh Reserved FEh, FFh Asynchronous: The data become valid when the PDO message is received and are taken over into the object dictionary. 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 belong together. Thus, 1600h with all subindices describes the first mapping, 1601h the second RX-PDO mapping, etc. Subindex 00h specifies how many objects are in a mapping. It simultaneously specifies how many of the subindices are valid. If object 1600h:00h 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 1600h:03h and 1600h:04h is, therefore, not active (shown in gray). Each subindex from 1600h:01h to 1600h:0Fh 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 6040h:00h. In hexadecimal notation, the content of 1600h:01h then consists of<Index><Subindex><Bit length>or 60400010. The second mapping (1600h:02h) contains the entry 607A0020. Thus, it maps the following four bytes (=20hBit) in object 607Ah:00h Dummy objects You can configure RX-PDOs so that more than one node can respond. In this case, it may be desirable for only part of the data contained in the PDO to be evaluated in one of the devices. For data not used locally, you can include a dummy object of one of the supported data types in the mapping of the PDO: Index Data type 0002h INTEGER8 0003h INTEGER16 0004h INTEGER32 0005h UNSIGNED08 0006h UNSIGNED16 0007h UNSIGNED32
TX configuration To configure a TX-PDO, you must take into account three object categories in the object dictionary: The objects that describe the functionality of the mapping. The objects that describe the content of the mapping. 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 1800h. The second mapping is configured in 1801h and so on. In the following, we refer to 180Nh. Here, the configuration affects the COB-ID of the PDO message and the transfer type. Objects 180Nh 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 (1A00h–1A03h), 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 1A04h–1A07h, the CAN-ID can be set independently (with the restriction that it not be used by other services, see table at the start of chapter CANopen services) 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)). Mapping COB-ID 1A00h 180h + Node-ID 1A01h 280h + Node-ID 1A02h 380h + Node-ID 1A03h 480h + Node-ID 1A04h xxxh + Node-ID 1A05h xxxh + Node-ID 1A06h xxxh + Node-ID 1A07h xxxh + Node-ID 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 180Nh:5). If 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. 180Nh:02h Meaning 0 Synchronous (acyclic): The data are copied to the TX-PDO upon arrival of the SYNC but are not sent until the Event. 01h-F0h Synchronous (cyclic): The data are copied upon arrival of the nth SNCY message and are sent immediately thereafter (n corresponds to the number 1 to 240, transmission type "1" sends the new data on each SYNC). F1h-FBh Reserved FCh RTR-Only (synchronous): The data are copied upon arrival of each SYNC message but are sent only upon request with an RTR message. FDh RTR-Only (event-driven): The data are copied to the TX-PDO message upon receipt of an RTR message and sent immediately thereafter. FEh, FFh The data are copied upon arrival of the Event and sent immediately. Subindex 3 (inhibit time): This subindex contains a time lock in 100 µs steps (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 (in ms) 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 slave is to initially respond to the sync and send the PDO. Not globally activated until a value greater than 1 is set in 1019h Synchronous Counter Overflow Value. Content of a 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 belong together. Thus, 1A00h with all subindices describes the first mapping, 1A01h the second TX-PDO mapping, etc. Subindex 00 specifies how many objects are in a mapping. It simultaneously specifies how many of the subindices are valid. If object 1A00h:00h is set to "0", TX mapping is thereby completely switched off. In the following example, two objects are thereby mapped in entries 1A00h:01h – 1A00h:02h. The objects in entries 1A00h:03h – 1A00h:04h are, thus, not mapped (shown in gray). Each subindex from 1A00h:01h to 1A00h:0Fh 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 6041h:00h. In hexadecimal notation, the content of 1A00h:01h then consists of <Index><Subindex><Bit Length>, or 60410010. The second mapping (1A00h:02h) contains the entry 60640020. Thus, it maps the following four bytes (corresponds to 32 bits) from object 6064h:00h in the TX-PDO message.
Presetting The following configuration is preset: RX-PDO 1. Mapping (CAN-ID: 200h + Node-ID): 6040h:00h (controlword) 6060h:00h (mode of operation) 3202h:00h (motor drive submode select) 2. Mapping (CAN-ID: 300h + Node-ID): 607Ah:00h (target position) 6081h:00h (profile velocity) 3. Mapping (CAN-ID: 400h + Node-ID): object 6042h:00h (vl target velocity) 4. Mapping (CAN-ID: 500h + Node-ID): object 60FEh:01h (digital outputs) TX-PDO 1. Mapping (CAN-ID: 180h + Node-ID): 6041h:00h (statusword) 6061h:00h (Modes Of Operation Display) 2. Mapping (CAN-ID: 280h + Node-ID): 6064h:00h (Position actual value) 3. Mapping (CAN-ID: 380h + Node-ID): 6044h:00h (vl velocity actual value) 4. Mapping (CAN-ID: 480h + Node-ID): object 60FDh:00h (digital inputs)
Changing PDO mapping You change the PDO mapping in the "Pre-operational" NMT state as follows: Deactivate the PDO by setting the Valid Bit (bit 31) of subindex 01h of the corresponding communication parameter (e.g., 1400h:01h) to "1". Deactivate the mapping by setting subindex 00h of the corresponding mapping parameter (e.g., 1600h:00h) to "0". Change the mapping in the desired subindices (e.g., 1600h:01h). Activate the mapping by writing the number of objects that are to be mapped in subindex 00h of the corresponding mapping parameter (e.g., 1600h:00h). Activate the PDO by setting bit 31 of subindex 01h of the corresponding communication parameter (e.g., 1400h:01h) to "0". Store the configuration by writing the value "65766173h" in 1010h:03h.
Boot-Up Protocol If the CAN slave reaches the "Pre-Operational" NMT state (see following figure), the following message is sent to signal operational readiness. This service is unconfirmed; there is no response. Note: The boot loader sends its own boot-up message. This can be suppressed, see object 2007h:00
Heartbeat and Nodeguarding With the "Heartbeat" and "Nodeguarding" services (often also referred to as "Lifeguarding"), switched-off or hung devices on the CAN bus can be found. For this purpose, the NMT master cyclically requests a message with the current NMT state of the slave (Nodeguarding). The alternative is that each slave sends a message unprompted and cyclically (Heartbeat). A combination of Nodeguarding and Heartbeat is not permissible. Furthermore, it is recommended that Heartbeat be given preference over Nodeguarding, as Nodeguarding results in a higher load on the CAN bus. Nodeguarding This service is based on the fact that the NMT master sends an RTR message with CAN-ID 700h + 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): guard time: The time between two RTR messages. This can be different for each CAN node and is stored in the slave in object 100Ch:00 (unit: milliseconds) live time factor: A multiplier for the guard time; this is stored in the CAN slave in object 100Dh:00 and can be different for each slave on the CAN bus. possible live time: The time produced by multiplying guard time and live time factor. The following conditions are checked during Nodeguarding: The NMT master must send the RTR request within the "possible live time". The slave must send the response to the RTR request within the "possible live time". The slave must respond with its NMT state. In addition, the "toggle bit" must be set correctly. Heartbeat If Heartbeat is activated, the slave sends its NMT state to the CAN bus unprompted and cyclically. You activate this service by setting the Producer Heartbeat Time time in object 1017h:00h to a value other than zero. The Producer Heartbeat Time is measured in milliseconds. The message sent by the slave has the form shown below: The slave must send the Heartbeat message within the Heartbeat Consumer Time. This time is known only to the master and is not stored in the controller. The slave can also monitor a Heartbeat from another producer (master or another slave). To do this, enter the Consumer Heartbeat Time and the node-ID of the producer in object 1016h. Errors that occur during this monitoring are reset if either the function is deactivated or the Heartbeat is again sent within the correct time.
Nodeguarding This service is based on the fact that the NMT master sends an RTR message with CAN-ID 700h + 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): guard time: The time between two RTR messages. This can be different for each CAN node and is stored in the slave in object 100Ch:00 (unit: milliseconds) live time factor: A multiplier for the guard time; this is stored in the CAN slave in object 100Dh:00 and can be different for each slave on the CAN bus. possible live time: The time produced by multiplying guard time and live time factor. The following conditions are checked during Nodeguarding: The NMT master must send the RTR request within the "possible live time". The slave must send the response to the RTR request within the "possible live time". The slave must respond with its NMT state. In addition, the "toggle bit" must be set correctly.
Heartbeat If Heartbeat is activated, the slave sends its NMT state to the CAN bus unprompted and cyclically. You activate this service by setting the Producer Heartbeat Time time in object 1017h:00h to a value other than zero. The Producer Heartbeat Time is measured in milliseconds. The message sent by the slave has the form shown below: The slave must send the Heartbeat message within the Heartbeat Consumer Time. This time is known only to the master and is not stored in the controller. The slave can also monitor a Heartbeat from another producer (master or another slave). To do this, enter the Consumer Heartbeat Time and the node-ID of the producer in object 1016h. Errors that occur during this monitoring are reset if either the function is deactivated or the Heartbeat is again sent within the correct time.
