logical consist network the way the data passes through the consist network without considering the physical interconnection of the End Devices Layer Setting Services services for adju
Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 11898-1, ISO 11898-2, IEC 61375-1, IEC 61375-2-1 and EN 50325-4, as well as the following apply
7-bit coded character set according to ISO/IEC 646
End Device connected to a CANopen-based consist network
Field device networked independent physical entity of an automation system capable of performing specified functions in a particular context and delimited by its interfaces
3.1.4 logical consist network the way the data passes through the consist network without considering the physical interconnection of the End Devices
3.1.5 logical device representation of a field device in terms of its objects and behavior according to a field device model that describes the device’s data and behavior as viewed through a network
Layer Setting Services services for adjusting bit rate and Node-ID via the communication interface of the CANopen device
Node-ID a) network-wide unique identifier for each CANopen device b) 7-bit coded Device Address in CANopen-based consist networks
Object entity with a well-defined boundary and identity that encapsulates state and behavior
3.1.9 virtual device entity of software capable of accomplishing a functional element of a field device
Abbreviations
For the purposes of this document, abbreviations given in ISO 11898-1, ISO 11898-2, IEC 61375-1, IEC 61375-2-1 and EN 50325-4, as well as the following apply
ASCII American Standard Code for Information Interchange
CRLF Carriage Return and Line Feed
SAS Service data object access service
Conventions
The conventions given in IEC 61375-1 shall apply
Content
This clause provides the definition of the architecture for Consist Networks based on CANopen.
Logical CANopen-based consist network
The Logical CANopen network connects multiple Virtual Devices and subsystems, as depicted in Figure 1 This CANopen-based Consist Network integrates various systems, including the Train Operating System (TOS), Monitoring and Safety System (MSS), Auxiliary Operating System (AUX), Power Drive System (PDS), Running Gear System (RGS), Brake Control System (BCS), Ancillary Operating System (ANC), Vehicle Linkage System (VLS), Exterior Lighting System (ELS), Interior Lighting System (ILS), Door Control System (DCS), HVAC System (HS), Passenger Information System (PIS), Diagnostic System (DS), and Train-to-Ground Communication System (TCS).
The Logical CANopen-based consist network interfaces with the Train Backbone through a Gateway, which facilitates information exchange and process data marshalling between the two systems.
Figure 1 – Logical network architecture of the consist network
Network topology
The network topology should resemble a single line structure with termination resistors at both ends, in accordance with ISO11898-2 Additionally, the overall network length must not exceed 450 meters when operating at a transmission rate of 125 kbit/s.
The total accumulated stub length must not exceed 110 m, with individual stubs limited to 22 m when operating at a transmission rate of 125 kbit/s It is advisable to minimize stub lengths for optimal performance Additionally, CAN transceiver chips should be galvanically isolated, with optocouplers positioned between the CAN controller and transceiver, which can influence the maximum bus length due to the propagation delay of the optocouplers Finally, termination resistors at both ends of the bus lines should be 120 Ω or higher.
The network topology is illustrated in Figure 2
Figure 2 – Network topology of CANopen-based consist network
Addressing
Each End Device connected to a CANopen-based Consist Network must have a unique CANopen Node-ID, which ranges from 01 h to 7F h This Node-ID can be configured using hardware switches or through software When adjusted via the device's CANopen communication interface, the CANopen Layer Setting Services are utilized.
PDS TOS MSS Gateway ELS
CANopen be used The CANopen Node-ID shall not be adjusted via the CANopen object dictionary of the related device
The definition of the Layer Setting Services (LSS) is not in the scope of this standard
NOTE LSS are specified in the document CiA 305.
Data classes
For effective data exchange within the CANopen-based Consist Network, both producers and consumers must understand the data format and its significance This requirement is addressed through the specification of data types.
The encoding rules specify how data type values are represented and the syntax for their transfer Data values are expressed as bit sequences, which are transmitted in octet (byte) sequences For numerical data types, the encoding follows a little-endian format.
Applications frequently necessitate data types that exceed basic options By utilizing the compound data type mechanism, one can expand the range of available data types Common extended data types include "Visible String" and "Time of Day." Compound data types serve as a method to implement user-defined "DEFTYPES," as outlined in EN 50325-4, rather than "DEFSTRUCTS."
The data types and encoding rules provided in EN 50325-4 shall apply
Content
This clause provides definitions for the physical layer of a CANopen-based consist network.
Cabling
The primary trunk circuit must consist of at least one twisted pair with a nominal characteristic impedance as specified in ISO 11898-2 Additionally, a CAN_Ground line should be implemented to provide a clear reference level for the voltage levels of CAN_H and CAN_L.
Connector
Devices in a CANopen-based network should utilize either the 9-pin D-sub connector or the 5-pin micro style (M12) connector, as shown in Figures 3 and 4 The 9-pin D-sub connector must adhere to the pinning specifications outlined in Table 1, while the 5-pin micro style connector (M12) should follow the pinning defined in Table 2 Additionally, since CANopen devices require galvanic isolation, the optional V+ line is designated solely for powering the CAN transceiver and optocoupler if no external power supply is available.
Figure 3 – 9-pin D-sub connector Table 1 – Pinning for 9-pin D-sub connector
2 CAN_L CAN_L bus line (dominant low)
5 (CAN_SHLD) Optional CAN shield
7 CAN_H CAN_H bus line (dominant high)
9 (CAN_V+) Optional CAN external positive supply (dedicated for supply of transceiver and optocouplers for galvanically isolated bus nodes)
NOTE It is highly recommended not to connect CAN_GND and GND
In case shielding is required, it is recommended to connect a shield via the metal housing of the used connector Optionally the CAN_SHLD pin can be used
Figure 4 – 5-pin micro style connector
Table 2 – Pinning for 5-pin micro style connector
1 (CAN_SHLD) Optional CAN shield
2 (CAN_V+) Optional CAN external positive supply (dedicated for supply of transceiver and optocouplers, if galvanic isolation of the bus node applies)
4 CAN_H CAN_H bus line (dominant high)
5 CAN_L CAN_L bus line (dominant low)
Physical medium attachment
Devices connected to CANopen-based networks must utilize a differentially driven two-wire bus line with a common return, adhering to the high-speed transmission specifications outlined in ISO 11898-2.
The high-speed transceiver compliant with ISO 11898-2 has a maximum rating of +16 V for both V CAN_H and V CAN_L While galvanic isolation between CANopen devices is optional, it is advisable to select a CAN transceiver that can withstand misconnection of any connector wires, including optional V+ voltages of up to 30 V.
Physical signaling
The bit encoding/decoding and synchronization shall meet the requirements defined in ISO 11898-1
The bit timing must adhere to the specifications outlined in ISO 11898-1, as detailed in Table 3 It is advisable to position the sample point as near as possible to 87.5% of the corresponding bit time.
Valid range for location of sample point
Devices connected to a CANopen-based consist network shall support a bit rate of 125 kbit/s Optionally further bit rates as given in Table 3 may be supported
Content
This clause provides definitions for the data link layer of a CANopen-based consist network.
CANopen data link layer
The described CANopen-based consist network shall be based on a data link layer and its sub-layers according to ISO 11898-1
This specification utilizes the 11-bit CAN-Identifier based on the CAN base frame format, eliminating the need to support the 29-bit CAN extended frame format.
Certain applications necessitate the use of the CAN extended frame format, allowing the network to function in this mode, provided that all connected CANopen devices are compatible with this format.
Content
This clause provides definitions with regard to the upper layers of the ISO OSI reference model for devices connected to a CANopen-based consist network.
Field device model
Devices connected to a CANopen-based consist network shall comply with the field device model as given in Figure 5
The field device, as depicted in Figure 5, must include at least one CANopen device, which should feature a network interface that encompasses the data link layer protocol and the physical layer Each CANopen device is required to have a unique Node-ID and at least one communication FSA, with the primary FSA incorporating the NMT slave state machine as specified in EN 50325-4 Additional FSAs may include an emergency state machine and others A CANopen device must support a minimum of one logical device, with the capability to support up to eight, where each logical device can house multiple virtual devices and optionally a logical device FSA Each virtual device is defined by its own FSA and is not shared among logical devices The minimum configuration of the field device is illustrated in Figure 6.
Communication FSA (NMT slave state machine)
A CANopen device is structured as shown in Figure 7:
• Communication – This function unit provides the communication objects and the appropriate functionality to transport data items via the underlying network structure
The object dictionary is a comprehensive collection of data items that significantly impact the behavior of application objects, communication objects, and the state machine utilized within the device.
• Application – The application comprises the functionality of the device with respect to the interaction with the process environment
CANopen communication objects
Devices connected to a CANopen-based consist network shall support all mandatory communication objects of EN 50325-4 as well as the CANopen network management state machine as defined in EN 50325-4
To simplify the configuration process for basic CANopen networks, a CAN-ID allocation scheme is established, allowing these CAN-IDs to be accessible in the NMT state Pre-operational immediately following the NMT state Initialization, provided no modifications have been saved The objects SYNC, TIME, EMCY write, and PDO can be deleted and recreated with new CAN-IDs through dynamic distribution Each CANopen device must supply the relevant CAN-IDs exclusively for the communication objects it supports, as outlined in EN 50325-4.
CANopen object dictionary
The CANopen object dictionary, outlined in EN 50325-4, supports up to 65,536 objects, each identified by a 16-bit index, and allows for as many as 256 sub-indices per object, which are accessed via an 8-bit sub-index.
The static data types at indices from 0001 h to 001F h contain type definitions for standard data types like BOOLEAN, INTEGER, UNSIGNED, floating point, string, etc
Complex data types at indices from 0020 h to 003F h are pre-defined structures that are composed of standard data types and are common to all CANopen devices
Manufacturer-specific complex data types at indices from 0040 h to 005F h are structures composed of standard data types but are specific to a particular CANopen device
CANopen device profiles can specify unique data types tailored to their specific device categories The static and complex data types outlined in the CANopen device profile are categorized within the index range of 0060 h to 025F h.
A CANopen device can optionally reveal the structure of its supported complex data types, specifically for indices ranging from 0020 h to 005F h and 0060 h to 025F h, through read access The sub-index 00 h indicates the highest sub-index available at that index, while the subsequent sub-indices present the data type encoded as UNSIGNED16 in accordance with EN 50325-4.
The communication profile area at indices from 1000 h to 1FFF h contains the communication specific parameters These objects are common to all CANopen devices
The standardized profile area, ranging from 6000 h to 9FFF h, encompasses all data objects shared among a class of CANopen devices, which can be accessed for reading or writing over the network These device profiles utilize objects within this range to define their parameters and functionalities.
The object dictionary concept allows manufacturers to include optional features in their CANopen devices While certain extended functionalities may not be provided, manufacturers can implement them in a standardized manner Specific indices in the object dictionary are reserved for this purpose.
2000 h to 5FFF h for manufacturer-specific functionality
The network variables at indices from A000 h to AFFF h contain input variables and output variables, which are part of a programmable CANopen device
The system variables at indices from B000 h to BFFF h contain input variables and output variables, which are part of an underlying CANopen network in a hierarchical sense
The general CANopen object dictionary structure is illustrated in Table 4
Table 4 – CANopen object dictionary structure
0040 h – 005F h Manufacturer-specific complex data types
0060 h – 025F h Device profile specific data types
2000 h – 5FFF h Manufacturer-specific profile area
6000 h – 67FF h Standardized profile area 1 st logical device
6800 h – 6FFF h Standardized profile area 2 nd logical device
7000 h – 77FF h Standardized profile area 3 rd logical device
7800 h – 7FFF h Standardized profile area 4 th logical device
8000 h – 87FF h Standardized profile area 5 th logical device
8800 h – 8FFF h Standardized profile area 6 th logical device
9000 h – 97FF h Standardized profile area 7 th logical device
9800 h – 9FFF h Standardized profile area 8 th logical device A000 h – AFFF h Standardized network variable area B000 h – BFFF h Standardized system variable area C000 h – FFFF h reserved
Predefined CANopen communication objects
Content
This clause provides the basic CANopen communication capability for CANopen devices that participate in a CANopen-based consist network according to this specification.
Object 1000 h : Device type
This device is characterized by its type and functionality, with a profile number of 0000 h indicating a logical device that does not adhere to a standardized profile If no additional logical device is implemented, the value remains 0000 h; otherwise, it changes to FFFF h when a further logical device is present.
For multiple logical device modules, the additional information parameter is FFFF h, and the device profile number referenced by object 1000 h corresponds to the first logical device in the object dictionary The profiles of other logical devices are identified at objects 67FF h + x * 800 h, where x is the internal number of the logical device (ranging from 1 to 8) minus 1 These objects define the device type of the preceding logical device, sharing the same value definition as object 1000 h.
Figure 8 illustrates the structure of the object The value definition, the object description and the entry description are specified in EN 50325-4
Additional information Device profile number
Figure 8 – Structure of the device type object
Devices on CANopen-based networks may adhere to the CANopen application profile for train vehicle control networks, as outlined in CiA 421 This profile specifies application data in accordance with UIC standards.
556, that is exchanged in a CANopen-based consist network.
Object 1001 h : Error register
This object conveys error information, with the CANopen device mapping internal errors into it The error details are included in the emergency message, and the definitions, descriptions, and entries are outlined in EN 50325-4.
Object 1014 h : COB-ID emergency object
This object shall be implemented It is specified in EN 50325-4 The CAN-ID, which is part of this object, shall not be changed.
Object 1017 h : Heartbeat producer
All CANopen devices that are connected to a CANopen-based consist network shall implement this object It is specified in EN 50325-4
The devices shall support heartbeat message transmissions from 100 ms to 1 000 ms.
Object 1018 h : Identity object
This object provides general information about the device as specified in EN 50325-4.
Object 1029 h : Error behavior
This object specifies to which state the device is set, in case a communication error or a device-internal error is detected It is specified in EN 50325-4.
Object 67FF h : Device type
This object shall describe the first logical device in a multiple device module according to EN 50325-4.
Service data objects (SDOs)
Any CANopen device supports the first SDO server channel CANopen devices connected to a CANopen-based consist network may support additional SDO server or client channels
In case an additional SDO channel is supported, the related SDO parameter set is supported in the CANopen object dictionary as defined in EN 50325-4
There are no further SDO channels pre-defined by this specification.
Process data objects (PDOs)
CANopen devices operated in a CANopen-based consist network may support up to 512 PDOs in transmit as well as receive direction
If a CANopen device supports a Process Data Object (PDO), it will include the corresponding PDO communication parameters and mapping entries in its object dictionary, as specified by EN 50325-4 It is important to note that there are no pre-defined PDOs.
Content
This clause provides the representation of application data that is communicated between a CANopen-based consist network and a Train Backbone via a Gateway
NOTE 1 The application data is described in application profile of TCN
In CANopen, application data is organized within the object dictionary index ranges of 2000 h to 5FFF h and 6000 h to 9FFF h The index range of 2000 h to 5FFF h is designated for manufacturer-specific device behavior, while the standardized device behavior is managed through objects in the index range of 6000 h to 9FFF h.
NOTE 2 Object dictionary entries in the index range 6000h to 9FFFh are specified in CANopen device and application profiles and available at CAN in Automation.
CANopen application data representation
As the application data for TCN is not defined yet, the representation of the TCN application data in the standardized object dictionary index range is not defined.
Recommended representation principle of application data
Content
This clause outlines a representation principle for application data within CANopen-based networks, enabling the mapping of processes to CANopen process data objects (PDOs) for efficient process data transfer.
Application data for door control
This clause provides the recommended representation principle by means of door control information, which is communicated between a CANopen-based consist network and a Train
Backbone via a Gateway The represented process data is therefore available in the CANopen-based consist network and can be communicated via the CANopen communication objects
The access type for the gateway device interface in a CANopen-based consist network is specified, allowing connected devices like door controllers to manage data according to the defined CANopen object dictionary index Additionally, the access type can be modified to align with the standards outlined in EN 50325-4.
NOTE The illustrated application data is derived from the document UIC 556 and is given in the representation of the CANopen application profile CiA 421 train vehicle control network.
Consumed door control application objects
8.3.3.1 Object 6007 h : External door status word export
The object is designed to indicate the status of the external doors of the local rail vehicle, with this information accessible through the Train Backbone gateway in the TCN The structure of the object is detailed in Figure 9, while Table 5 provides the value definitions, Table 6 outlines the object description, and Table 7 presents the entry description.
NOTE The object shall correspond to R3-telegram octet 20, which is defined in UIC 556
Bit 7 reserved Bit 5 Bit 4 reserved
Figure 9 – Object structure Table 5 – Value definition
Bit4 0 At least one left door is open
1 All left doors locked Bit 5 0 At least one right door is open
1 All right doors locked Bit 7 0 Side selective door blocking is not in operation
1 Side selective door blocking is in operation Reserved Reserved (shall be ignored)
Name External doors status word export Object code Variable
Data type UNSIGNED8 Category Optional
PDO mapping Optional Value range See value definition Default value Manufacturer specific
Produced door control application objects
8.3.4.1 Object 6006 h : External door status word import
The object provides the status of external doors for various rail vehicles, with each sub-index corresponding to the UIC vehicle number This information is accessible within the CANopen-based consist network, and the overall door status for all vehicles is detailed in sub-index 21 h The object structure is illustrated in Figure 10, while Table 8 defines the values, Table 9 describes the object, and Table 10 outlines the entry details.
NOTE The object shall correspond to R3-telegram octet 20, which is defined in UIC 556
Bit 7 reserved Bit 5 Bit 4 reserved
Figure 10 – Object structure Table 8 – Value definition
Bit4 0 At least one left door is open
1 All left doors locked Bit 5 0 At least one right door is open
1 All right doors locked Bit 7 0 Side selective door blocking is not in operation
1 Side selective door blocking is in operation Reserved Reserved (shall be ignored)
Name External doors status word import Object code ARRAY
Data type UNSIGNED8 Category Optional
Sub-index 00 h Description Highest subindex supported Entry category Mandatory
PDO mapping No Value range 01 h to 21 h Default value No
Sub-index 01 h Description Door status UIC vehicle 1 Entry category Optional
PDO mapping Optional Value range see Table 46 Default value No to Sub-index 20 h Description Door status UIC vehicle 32 Entry category Optional
PDO mapping No Value range Optional Default value No
Sub-index 21 h Description Door status train Entry category Optional
PDO mapping No Value range Optional Default value No
This object serves as the initial control word for the external doors The structure of the object is detailed in Figure 11, while Table 11 outlines the value definitions Additionally, Table 12 provides a description of the object, and Table 13 offers an entry description.
NOTE The object shall correspond to R3-telegram octet 20, which is defined in UIC 556
Reserved Bit 6 Reserved Bit 3 Bit 2 Bit 1 Bit 0
1 Interrupt door closing Bit 2 0 Release all left doors
1 Lock all left doors Bit 3 0 Release all right doors
1 Lock all right doors Bit 6 0 Not extend footstep
1 Extend footstep Reserved Reserved (shall be ignored)
Name External door command 1 Object code Variable
Data type UNSIGNED8 Category Optional
PDO mapping Optional Value range See value definition Default value No
Content
This clause outlines the network management for CANopen-based consist networks, detailing the network startup behavior and specifications for networks operating without an NMT master, as well as those with a single CANopen device capable of NMT master mode These definitions serve as an enhancement to the CANopen application layer and communication profile specified in EN 50325-4.
CANopen networks that include multiple devices capable of NMT master mode (NMT flying master) are not covered by this specification, but they are not excluded from consideration.
In CANopen-based networks, multiple devices with NMT master functionality can exist, but only one can be active at any given time To facilitate the transition of NMT master functionality between devices, specific mechanisms are necessary These services are encompassed within the CANopen flying master functionality, as outlined in CiA 302.
CANopen NMT slave functionality
Devices in a CANopen-based network must support CANopen NMT-slave functionality and implement all required communication services, protocols, and mandatory objects as outlined in EN 50325-4, with the minimum communication objects specified in section 7.6.
Optionally further communication objects may be supported In addition the CANopen manager functionality may be supported.
CANopen manager functionality
General
This subclause provides the definition of the CANopen manager functionality for CANopen- based consist networks
Besides the application process several different additional functionalities exist in a CANopen network These functionalities are referred to by different terms This subclause is intended to clarify these terms
In a distributed system, the application process is segmented into multiple components operating on various CANopen devices Typically, one CANopen device, known as the application master, oversees the control of the entire system from the application's perspective.
From a network perspective, various supplementary functionalities exist that, while not directly related to the application itself, offer essential support These functionalities are structured around relationships such as master/slave, client/server, or producer/consumer.
As it is common to combine several of the additional functionalities in one CANopen device the term CANopen Manager is introduced
A CANopen device is referred to as CANopen manager, if it provides the NMT master functionality and at least one of the functionalities SDO manager or Configuration manager
Network management (NMT) oversees the behavior of CANopen devices as outlined in EN 50325-4 In a CANopen network, all devices, known as NMT slaves, are managed by an NMT master, which typically functions as part of the application master.
The device is a fully CANopen-compliant unit that incorporates NMT master functionality and supports all mandatory functions and objects as specified in EN 50325-4.
The flying master mechanism offers services for a hot stand-by NMT master in a CANopen network This optional feature allows a CANopen device to perform NMT master functions However, the specific responsibilities, functionalities, and services of the flying master are not covered in this document.
NOTE Definitions for the flying master functionality are provided in CiA 302
The SDO manager is an optional feature that manages the dynamic establishment of SDO connections within a CANopen network When implemented, the SDO manager operates alongside the NMT master on the same CANopen device.
NOTE Definitions for the SDO manager functionality are provided in CiA 302
The Configuration Manager is an optional feature that facilitates the configuration of CANopen devices within a CANopen network during the boot-up process This functionality, known as Configuration Management (CMT), operates alongside the NMT master on the same CANopen device when present in the network.
NOTE Definitions for the Configuration manager functionality are provided in CiA 302
The SYNC producer is an optional feature that transmits the SYNC object and can be implemented on any device within a CANopen-based network The associated entries for the CANopen object dictionary are specified in the EN 50325-4 standard.
The TIME producer is an optional feature that transmits the TIME STAMP object and can be implemented on any device within a CANopen-based network This time stamp object is specified in the EN 50325-4 standard.
Layer Setting Services (LSS) facilitate the configuration of layer 2 (bit timing) and NMT (CANopen Node-ID) through CAN The LSS master is responsible for configuring LSS slaves by executing specific LSS services This document does not cover the definition of Layer Setting Services.
NOTE Definitions for the layer setting services are provided in CiA 305.
Object dictionary usage
In CANopen device configuration and validation, several objects are categorized as ARRAY type, with their sub-index entries corresponding to the CANopen Node-ID These objects can have fewer than 127 entries, and all must share the same set of supported entries The sub-index 00 h indicates the highest supported sub-index at this index, a concept referred to as the SupportedNodeID condition in Clause 9.
NOTE For a CANopen manager to be universally usable it is recommended to support the full sub-index range of
Redundant networks
Redundant networks are essential for high-availability applications, comprising at least two CAN lines to ensure communication between CANopen devices in the event of a single failure in their physical interconnection This document does not cover the definition of responsibilities, functionalities, and services related to redundant networks.
NOTE Definitions for setting up redundant CANopen networks are provided in CiA 302.
CANopen NMT start-up
NMT startup
CANopen managers must adhere to the NMT slave state machine outlined in EN 50325-4 Prior to transitioning from the Pre-operational to the Operational state, all assigned NMT slaves must be booted The primary procedure flow chart is illustrated in Figures 12 and 13, while the simplest startup flow chart is shown in Figure 14.
Not defined yes in this document yes
Keep alive bit of some of the CANopen devices set? no
NMT service Reset communication for each CANopen device individually whom keep alive bit is not set
Reset communication with Node ID set to 0 no yes
The process NMT startup as shown in Figure 12 consists of the following basic steps:
NOTE 1 The process execute LSS master is not in the scope of this standard a) Bit 0 of object 1F80 h (see clause 9.8.7) is used to decide whether this CANopen device shall be the NMT master If the CANopen device is NMT master the process shall continue If the CANopen device is configured as self-starting device, it shall enter the NMT state Operational automatically In case the CANopen device is not the NMT master the process shall end b) Bit 5 of object 1F80 h (see clause 9.8.7) is used to decide whether this CANopen device shall participate in the service NMT flying master negotiation If the CANopen device shall participate in the service NMT flying master negotiation and the CANopen device lost the service NMT flying master negotiation the CANopen device shall not become NMT master
The definition of the NMT flying master negotiation is not in the scope of this document
NOTE 2 The description of the NMT flying master negotiation is provided in CiA 302 c) If LSS is required to set the CANopen Node-ID and bit rate of other CANopen devices within the network the NMT master shall execute the LSS master services The LSS master services may be executed at any time The precise definition of the LSS master services is not in the scope of this document
NOTE 3 The description of the layer setting services is provided in CiA 305 d) Bit 4 of all entries of object 1F81 h (see clause 9.8.8) is used to decide whether the NMT master shall perform the NMT service Reset communication with CANopen Node-ID set to
The NMT service Reset communication must be executed individually for each CANopen device in the network If any entry of object 1F81 with bit 4 set to 1b corresponds to a CANopen device in the Operational state, the NMT master is prohibited from issuing the Reset communication for the CANopen Node-ID set to 0 Consequently, each CANopen device must be reset separately, including those Node-IDs not included in the slave list 1F81.
NOTE 4 This will force potentially existing CANopen devices that are not configured in the slave list to transmit a boot-up message By this the CANopen Manager will recognize unconfigured CANopen devices via the boot-up handler (Figure 23) The NMT service Reset communication shall not apply to the NMT master itself
If a reset of the NMT communication is required after step d), it must be performed using the CANopen Node-ID of the respective NMT slave, regardless of its configuration in object 1F81 h The NMT startup process continues as illustrated in Figure 13.
Start boot NMT slave Start boot NMT slave Start boot NMT slave
Start process NMT slave boot
All mandatory NMT slaves booted?
Enter myself automatically NMT state
Enter NMT state Operational from application received? no no
Enter myself NMT state Operational yes yes
All optional NMT slaves started successfully?
NMT service Start remote node with node-ID set to 0 yes no
Start NMT slaves with NMT start all nodes? yes no
NMT service Start remote node for each NMT slave individually
The NMT master initiates the process to boot all NMT slaves, as illustrated in Figure 15 For mandatory NMT slaves, indicated by bits 0 and 3 of object 1F81 h, the boot process must complete successfully If any errors occur during the booting of these mandatory slaves, the NMT startup process will be halted Additionally, bit 2 of object 1F80 h determines whether the NMT master automatically transitions to the Operational state or waits for a request from the application on the same CANopen device.
– Bit 3 of object 1F80 h is set to 0 b ,
– Bit 1 of object 1F80 h is set to 1 b ,
– and all NMT slaves listed in 1F81 h booted successfully the NMT service Start remote node shall be performed with CANopen Node-ID set to 0 Under the following conditions
– Bit 3 of object 1F80 h is set to 0 b ,
– Bit 1 of object 1F80 h is set to 1 b ,
Not all NMT slaves listed in 1F81 h booted successfully, so the NMT service start must be performed for each NMT slave individually Once the NMT startup process is completed successfully, the NMT master can continue with normal operations.
Occurrence and detection of NMT slaves not listed in 1F81 h falls into the responsibility of the application.
NMT startup simple
A basic NMT master can be implemented for certain applications, as most objects and features are optional By eliminating all optional components, the NMT startup process becomes straightforward, as illustrated in Figure 14 This simplified NMT master still accommodates all mandatory objects outlined in EN 50325-4, adhering to the definitions provided in the standard.
NMT service Reset communication with Node ID set to 0
NMT service Start remote node with
Node ID set to 0 (time not specified)
Start process boot NMT slave
Start parallel process boot NMT slave Boot NMT slave Wait 1s asynchronously
End of start process boot NMT slave
Error status B? no yes Is must bit set and boot time elapsed? no
Inform application yes no yes
Signal successfull boot or elapsed time
Signal first boot access on optional NMT slave
Figure 15 – Start process boot NMT slave
The booting process for the NMT slave, as illustrated in Figure 15, involves several key steps: a) initiating the parallel process to boot the NMT slave, and b) ensuring that mandatory NMT slaves wait for the completion of the booting process.
Optional NMT slaves require a signal indicating that the Boot NMT slave process has been executed The parallel process will perform the Boot NMT slave operation and generate a signal for each attempt of this process.
If the process boot NMT slave returned with status OK the process shall terminate
This process shall run endlessly for any optional NMT slave until the process Boot NMT slave finishes with status OK
NOTE The recommended cycle time is 1 s for bit rate higher than 125 kbit/s
If the boot process for mandatory NMT slaves returns an error status B and the elapsed time exceeds the configured value of object 1F89 h, the application must be notified, and this sub-process will terminate.
The sub-process of the process start process boot NMT slave shall run asynchronously to other processes.
Boot NMT slave
Check configuration
Expected configuration date and time non-zero?
Request object 1020 h from CANopen device
DCF of the CANopen device
End of check configuration with OK status End of check configuration with error status J
The configuration check process, illustrated in Figure 19, involves several key steps: a) The entries corresponding to the CANopen Node-ID in object 1F26 h and object 1F27 h are evaluated to verify the configuration of CANopen devices If both values are equal to 0, the process proceeds to step d).
If the values are not zero, the process will proceed to request object 1020 h from the CANopen device Subsequently, the values of the corresponding entries, where the sub-index matches the CANopen Node-ID, of objects 1F26 h and 1F27 h will be compared to the values of the received object.
1020 h If the values are equivalent the process shall finish with status OK
If the values are not equivalent the process shall go to step d) d) The configuration shall be updated on the CANopen device
The configured restore operation will be executed based on the settings of 1F81 h and 1F8A h The NMT service reset communication or NMT service reset node for the corresponding NMT slave will only be issued after the completion of the restore operation.
The configuration for a CANopen device can be obtained from any available Device Configuration File (DCF) This DCF can be accessed from a local file system or through objects 1F20h or 1F22h on the configuration manager Upon successful download, the process will conclude with a status of OK; otherwise, it will end with an error status.
If the keep-alive feature is activated for a CANopen device and the device is in the Operational NMT state, the process check configuration can be bypassed In such cases, the process boot for the NMT slave will conclude with an error status indicating that the "NMT slave was initially operational."
Check NMT state
Send RTR to request for the node guard response no
Consumer heartbeat time elapsed? no no yes
End of check NMT state with error status E yes
End of check NMT state with actual state of the CANopen device
Node guard confirmation received? yes
100 ms elapsed from sending RTR? no no yes
End of check NMT state with error status F
The NMT state check process, illustrated in Figure 20, involves several key steps: First, Object 1016 h (referencing EN 50325-4) is utilized to determine if the CANopen device is configured for heartbeat monitoring If it is, the NMT master must verify the timely receipt of a heartbeat indication; failure to do so results in an error status Conversely, if the heartbeat is received, the process concludes with the current NMT state of the device If the device is not set up for heartbeat, it is presumed to be configured for CANopen device guarding, prompting the NMT master to request the device's current NMT state using the CANopen device guarding service Should no confirmation be received within 100 ms, the process will also end with an error status; however, if confirmation is received, the process will conclude with the actual NMT state of the device.
NMT flying master start up
The definition of the flying NMT master is not in the scope of this standard
NOTE Definitions for the flying NMT master functionality are provided in CiA 302
1 Required, if bit 4 of object 1F81 h is set (keep alive supported).
Error status
The errors as shown in Table 14 shall be signaled within the NMT master during startup
A The CANopen device is not listed in object 1F81 h
B No response received for upload request of object 1000 h
C Value of object 1000 h from CANopen device is different to value in object 1F84 h (Device type)
D Value of object 1018 h sub-index 01 h from CANopen device is different to value in object
E Heartbeat event No heartbeat message received from CANopen device
F Node guarding event No confirmation for guarding request received from CANopen device
G Object 1F53 h or object 1F54 h not configured for that CANopen device
H Values of object 1F52 h from that CANopen device are different to value of object 1F53 h or value of object 1F54 h and bit 6 of object 1F81 h is not set
I Values of object 1F52 h from that CANopen device are different to value of object 1F53 h or value of object 1F54 h and download failed
K Heartbeat event during start error control service No heartbeat message received from
CANopen device during start error control service
L NMT slave was initially operational (CANopen manager may resume operation with other
M Value of object 1018 h sub-index 02 h from CANopen device is different to value in object
N Value of object 1018 h sub-index 03 h from CANopen device is different to value in object
O Value of object 1018 h sub-index 04 h from CANopen device is different to value in object
Error control
Start error control
Node ID in network list? no yes
Start node guarding no yes yes
The error control process for CANopen devices involves several key steps: First, it checks if the device is configured for heartbeat monitoring If the device is set for heartbeat but fails to receive a timely indication, the process concludes with an error status, initiating a timeout timer Conversely, if a heartbeat indication is received on time, the process successfully concludes If the device is not configured for heartbeat, bit 0 of object 1F81 h determines if it should be guarded If the device is absent from the network list, the process ends successfully However, if it is present, the values of bytes 2 and 3 of object 1F81 h are evaluated to decide on guarding If these values exceed 0, guarding begins, and the process concludes successfully; if they equal 0, the process also ends successfully.
Error handler
Stop all nodes? no yes
Reset all nodes? no yes no
Stop remote node with Node ID set to 0
Reset node with Node ID set to 0
Reset node with Node ID of that CANopen device
Boot NMT slave for that CANopen device
Bit 0 Bit 3 Bit 3 Bit 6 Bit 4
The process error handler as defined in Figure 22 shall be initiated any time an NMT error event occurs.
Bootup handler
Boot NMT slave for that CANopen device
The process bootup handler as defined in Figure 23 shall be initiated any time a bootup event occurs (see EN 50325-4).
Additional NMT master services and protocols
The definition of additional NMT master services and protocols is not in the scope of this specification
NOTE Additional NMT master services and protocols such as NMT master negotiation or NMT master detection services are provided in CiA 302.
Object dictionary entries
Object 1020 h : Verify configuration
The object indicates the date and time of the downloaded configuration If a CANopen device can save parameters in non-volatile memory, a network configuration tool or CANopen manager uses this object to verify the configuration after a reset and determine if reconfiguration is needed The configuration tool records the date and time in this object and also in the DCF It allows the CANopen device to save its configuration by writing to index 1010 h sub-index 01 h the signature.
After a reset, the CANopen device will automatically restore the last configuration and signature, or this can be done upon request If any command alters the boot-up configuration values, the device will reset the object Verify Configuration to 0.
The Configuration Manager compares signature and configuration with the value from the DCF and decides if a reconfiguration is necessary or not
Utilizing this object significantly accelerates the boot-up process When implemented, the system integrator assumes that a user modifies a configuration value and subsequently activates the command to store the configuration at 1010h, without altering the value at 1020h This approach guarantees a consistent and complete utilization of this feature by the system integrator.
Sub-index 01 h represents the number of days elapsed since January 1, 1984, while Sub-index 02 h indicates the milliseconds that have passed since midnight For detailed information, refer to Table 15 for the object description and Table 16 for the entry description.
Description Highest sub-index supported
Default value Manufacturer-specific to
Object 102A h : NMT inhibit time
This object specifies the configured inhibit time between consecutive NMT messages Outstanding NMT services will be queued and issued in the order they occur, adhering to the configured inhibit time Refer to Table 17 and Table 18 for the object and entry descriptions.
The value shall be given in multiples of 100 às The value 0 shall disable the inhibit time
Object 1F20 h : Store DCF
This object shall be used to save the current configuration for a specific CANopen device in the network Table 19 defines the object description and Table 20 defines the entry description
The sub-index of an entry must match the CANopen Node-ID of the device within the network, and this specific sub-index is utilized for self-configuration In cases where no Device Configuration File (DCF) has been previously saved, a read access will trigger an SDO abort message, indicated by error codes 0800 0024 h or 0800 0000 h It is important to note that the definition of the DCF format is beyond the scope of this specification.
NOTE The format of DCF is provided in CiA 302
Value range See value definition
Default value Manufacturer-specific to
Value range See value definition
Object 1F22 h : Concise DCF
This object shall be used to save the current configuration for a specific CANopen device in the network Table 21 defines the object description and Table 22 defines the entry description
The sub-index of an entry must match the CANopen Node-ID of the device within the network, and this specific sub-index is utilized for self-configuration The Device Configuration File (DCF) format is outlined in Figure 24 If no DCF has been previously saved, the entry count will be zero Additionally, if a DCF for a particular entry is deleted, the entry count will also be reset to zero.
Size (m) of data in bytes UNSIGNED32
Size (m) of data bytes UNSIGNED32
Size (m) of data bytes UNSIGNED32
Figure 24 – Data stream definition of concise DCF
Default value Manufacturer-specific to
Object 1F26 h : Expected configuration date
This object shall be used for verification of the configuration date of the CANopen devices in the network
The configuration date of CANopen devices in the network must align with the value of object 1020 h sub-index 01 h, provided this value is not equal to 0 If the value is 0, the CANopen device should be configured accordingly.
The sub-index of an entry shall correspond to the CANopen Node-ID of the CANopen devices in the network
Default value Manufacturer-specific to
Object 1F27 h : Expected configuration time
This object shall be used for verification of the configuration time of the CANopen devices in the network
The configuration time for CANopen devices (object 1020 h sub-index 02 h) must align with the value of this object if it is not equal to 0 If the value is 0, the CANopen device should be configured accordingly.
The sub-index of an entry shall correspond to the CANopen Node-ID of the CANopen devices in the network
NOTE Object description and entry description of index 1020h sub-index 02h are provided in the latest CANopen version; document CiA 301
Value range See value definition
Default value Manufacturer-specific to
Object 1F80 h : NMT startup
The startup behavior of a CANopen device is configured by this object, which remains unaffected by internal state transitions Any attempt to modify unsupported functionality will result in an abort message, specifically with abort codes 0800 0000 h or 0609 0030 h The bit-oriented structure of the value is illustrated in Figures 25 and 26, while Tables 27 through 33 outline the permissible values Additionally, Table 34 specifies exceptions for start-up capable devices, and Tables 35 and 36 provide the object and entry descriptions, respectively.
Stop all nodes Flying master Reset all nodes Start node NMT master start
Start all nodes NMT master
Figure 26 – Bit structure of the configuration value
Table 27 – Value NMT master (bit: 0)
0 b CANopen device is not NMT master
The entries of the object 1F81 h shall be ignored All other bits of object 1F80 h shall be ignored with the exceptions defined in Table 34
1 b CANopen device is the NMT master
Table 28 – Value Start all nodes (bit: 1)
0 b NMT service start remote node for each CANopen Node-ID
1 b NMT service start remote node with CANopen Node-ID = 0
Table 29 – Value NMT master start (bit: 2)
0 b Shall switch into NMT state Operational in the process NMT startup (see Figure 13)
1 b Shall not switch into the NMT state Operational by itself
Table 30 – Value Start node (bit: 3)
0 b The NMT master shall start the NMT slaves
1 b The NMT master shall not start the NMT slaves and the application may start the NMT slaves
Table 31 – Reset all nodes (bit: 4)
In the event of a mandatory error control occurrence in a CANopen device, as specified in object 1F81 h, the NMT service must execute a reset node for the CANopen Node-ID associated with the device that triggered the error control event.
1 b In case of error control event of a CANopen device defined as mandatory (see object 1F81 h ) the NMT service reset node with CANopen Node-ID = 0 shall be executed
0 b CANopen device shall not participate the NMT flying master negotiation
1 b Reserved (for NMT flying master capable devices)
NOTE The definition of the NMT flying master functionality is not in the scope of this standard Definitions are provided in CiA 302
Table 33 – Stop all nodes (bit: 6)
0 b In case of error control event of a CANopen device defined as mandatory (see object 1F81 h ) the action as defined by bit 4 shall be executed
1 b In case of error control event of a CANopen device defined as mandatory (see object 1F81 h ) the NMT service Stop remote node with CANopen Node-
ID = 0 shall be executed Bit 4 shall be ignored
Table 34 – Exceptions for NMT start-up capable devices
00000000 00000000 00000000 00001000 b NMT slave that shall enter the NMT state Operational after the NMT state Initialisation autonomously (self starting)
00000000 00000000 00000000 00000010 b NMT slave that shall execute the NMT service start remote node with CANopen Node-ID set to 0
Mandatory if the CANopen device is a CANopen manager or a start-up capable CANopen device
Value range See value definition
Object 1F81 h : NMT slave assignment
This object shall assign CANopen devices to the CANopen manager, the device that shall implement this object Each sub-index of this object shall correspond to the CANopen Node-
The ID of the related CANopen device within the network should be noted, while the sub-index associated with its own CANopen Node-ID must be disregarded If there is an attempt to modify a functionality that the CANopen device does not support, it will respond with an abort message, accompanied by an appropriate abort code.
The bit-oriented structure of the value is illustrated in Figures 27 and 28 The contents of the value are detailed in Tables 37 through 43, while Tables 44 and 45 provide definitions for the object description and entry description, respectively.
The retry factor determines how many times the NMT master will attempt to retry during a node guarding event Setting this value to 0 will disable node guarding for the CANopen device.
The guard time value specifies the cycle time for node guarding in a CANopen device, expressed in milliseconds Setting the value to 0 will disable node guarding for the device.
NOTE If the heartbeat consumer object is configured to a value unequal to 0, then the heartbeat mechanism will have priority over node guarding
Guard time Retry factor Configuration
Figure 27 – Object structure of the value
7 6 5 4 3 2 1 0 Restore Software update Software version Reset communication Mandatory NMT boot slave reserved
Figure 28 – Bit structure of the configuration value
0 b NMT master or not available in the network
1 b NMT slave and available in the network
Table 38 – NMT boot slave (bit: 2)
0 b Configuration and NMT service Start remote node shall not be allowed in case of error control event or NMT service Bootup
NOTE The application is responsible for the NMT slave startup
1 b Configuration and NMT service Start remote node shall be performed in case of error control event or NMT service Bootup
0 b CANopen device may be present prior to network startup (CANopen device is optional)
1 b CANopen device shall be present prior to network startup (CANopen device is mandatory)
0 b NMT service Reset communication may be executed for the CANopen device at any time
1 b NMT service Reset communication shall not be executed for the CANopen device in case the CANopen device is in NMT state Operational
0 b Software version verification shall not be performed for the CANopen device
1 b Software version verification shall be performed for the CANopen device
0 b Software update shall not be performed for the CANopen device
1 b Software update shall be performed for the CANopen device
0b CANopen device may be used without prior resetting
1b CANopen device shall be reset to factory defaults by issuing a restore to defaults (object 1011 h )
Category Conditional; mandatory if the CANopen device is a CANopen manager
Value range see Figure 27, Figure 28,Table 37, Table 38, Table 39, Table 40,
Table 41, Table 42, and Table 43 Default value 0000 0000 h to
Value range see Figure 27, Figure 28,Table 37, Table 38, Table 39, Table 40,
Table 41, Table 42, and Table 43 Default value 0000 0000 h
Object 1F82 h : Request NMT
This object is designed to request a specific NMT service for either a unique CANopen device or for all devices in the network when the requesting device operates in NMT master mode Typically, the request is initiated by another CANopen device, such as a configuration tool, or by the application running on the same CANopen device, particularly in an IEC 61131 environment.
The sub-index corresponds to the CANopen Node-ID of devices within the network, and these requests can also be applied to the NMT master The value contents are defined in Table 46, while Tables 47 and 48 provide the object and entry descriptions, respectively.
To successfully process values from 84 h to 8F h, it is essential to know the CANopen Node-ID of the requesting device If the Node-ID is not known, the service must be aborted, with the corresponding abort codes being 0800 0000 h or 0609 0030 h.
An attempt to download a value that is reserved shall be responded with an SDO abort message (abort code: 0800 0000 h or 0609 0030 h )
NOTE The values from 00 h to 7F h have to be applied carefully to not unintentionally affect the NMT master or the requesting CANopen device itself
Value Description on upload (read) on download (write)
04 h NMT state Stopped NMT service Stop remote node
05 h NMT state Operational NMT service Start remote node
06 h reserved NMT service Reset node
07 h reserved NMT service Reset communication
7F h NMT state Pre-operational NMT service Enter pre-operational
84 h NMT state Stopped NMT service Stop remote node
(excluding NMT master and requesting CANopen device)
85 h NMT state Operational NMT service Start remote node
(excluding NMT master and requesting CANopen device)
86 h reserved NMT service Reset node
(excluding NMT master and requesting CANopen device)
87 h reserved NMT service Reset communication
(excluding NMT master and requesting CANopen device)
8F h NMT state Pre-operational NMT service Enter pre-operational
(excluding NMT master and requesting CANopen device)
Object 1F83 h : Request node guarding
This object requests node guarding for a specific CANopen device or for all devices in the network when the implementing device is in NMT master mode with node guarding enabled Typically, this request is made by another CANopen device, such as a configuration tool, or by the application on the same CANopen device, particularly in an IEC 61131 environment.
The sub-index should align with the CANopen Node-ID of the devices within the network, while the sub-index that matches its own CANopen Node-ID will be disregarded The value contents are outlined in Table 49, with Table 50 and Table 51 providing the object and entry descriptions, respectively.
An attempt to download a value that is reserved shall be responded with an abort message (abort code: 0800 0000 h or 0609 0030 h )
NOTE Heartbeat consumer is covered by object 1016h (see CiA301)
Value Description on download (write) on upload (read)
00 h Stop node guarding Node guarding stopped
01 h Start node guarding Node guarding started
Object 1F84 h : Device type identification
This object is used for verification of the device type of the CANopen devices in the network
The CANopen device in the network must have its device type (object 1000 h – see EN 50325-4) verified against the corresponding value; an error event will occur if there is a mismatch If the value is 0, the device type verification is not required Refer to Table 52 and Table 53 for the object and entry descriptions.
The sub-index will align with the CANopen Node-ID of the devices within the CANopen network, while the sub-index that matches its own CANopen Node-ID will be disregarded.
Value range See value definition of object 1000h – EN 50325-4
Value range See value definition in EN 50325-4 of object 1000h
Object 1F85 h : Vendor identification
This object shall be used for verification of the Vendor ID of the CANopen devices in the network
The Vendor ID (object 1018 h sub-index 01 h as per EN 50325-4) of a CANopen device must be compared to its corresponding value in the network, triggering an error event if they do not match If the Vendor ID value is 0, verification of the CANopen device's Vendor ID is not required Refer to Table 54 and Table 55 for detailed object and entry descriptions.
The sub-index will align with the CANopen Node-ID of the devices within the network, while the sub-index that matches its own CANopen Node-ID will be disregarded.
Value range See value definition in EN 50325-4 object 1018h sub-index 01h
Value range See value definition in EN 50325-4 object 1018h sub-index 01h
Object 1F86 h : Product code
This object shall be used for verification of the product code of the CANopen devices in the network
The product code of the CANopen device in the network, identified as object 1018 h sub-index 02 h (refer to EN 50325-4), must be verified to ensure it matches the corresponding value of this object, provided that the values are not equal.
0 An error event shall be generated if the values mismatch In case the value of this object is
0 the product code of the CANopen device in the network may not be verified Table 56 and Table 57 define the object description and the entry description
The sub-index will align with the CANopen Node-ID of the devices within the CANopen network, while the sub-index that matches its own CANopen Node-ID will be disregarded.
Value range See value definition of EN 50325-4 object 1018h sub-index 02h
Value range See value definition in EN 50325-4 object 1018h sub-index 02h
Object 1F87 h : Revision number
This object shall be used for verification of the revision number of the CANopen devices in the network
The CANopen device's revision number (object 1018 h sub-index 03 h – see EN 50325-4) must be compared to the corresponding value of this object, and an error event will occur if the values are not equal to 0 A mismatch is defined as any discrepancy between these values.
• the major revision number is unequal to the expected major revision number, or
• the minor revision number is less than the expected minor revision number,
If the value of this object is 0, the revision number of the CANopen device in the network will not be verified The object description and entry description are outlined in Table 58 and Table 59.
The sub-index will align with the CANopen Node-ID of the devices within the network, while the sub-index that matches its own CANopen Node-ID will be disregarded.
Value range See value definition of object 1018 h sub-index 03 h – EN 50325-4
Value range See value definition of object 1018 h sub-index 03 h – EN 50325-4
Object 1F88 h : Serial number
This object shall be used for verification of the serial number of the CANopen devices in the network
The serial number of the CANopen device, identified as object 1018 h sub-index 04 h (refer to EN 50325-4), must be verified against the corresponding value of this object if the values do not match.
0 An error event shall be generated if the values mismatch In case the value of this object is
0 the serial number of the CANopen device in the network may not be verified Table 60 and Table 61 define the object description and the entry description
The sub-index will align with the CANopen Node-ID of the devices within the CANopen network, while the sub-index that matches its own CANopen Node-ID will be disregarded.
Value range See value definition of EN 50325-4 object 1018 h sub-index 04 h
Value range See value definition of EN 50325-4 object 1018 h sub-index 04 h
Object 1F89 h : Boot time
The object specifies the timeout duration between the initiation of the process to start the NMT slave and the confirmation of successful booting of all required NMT slaves, as outlined in section 9.4.3.
The value shall be given in multiples of ms The value 0 shall disable the timer Table 62 provides the object description and Table 63 the entry description
Object 1F8A h : Restore configuration
This object is used to define the allowed restore procedure for a CANopen device during startup
The restore procedure outlined in this object is designed to be utilized during startup to restore each CANopen device within the network, as specified in object 1011 h (refer to EN 50325-4) The details of the object and entry descriptions are provided in Table 64 and Table 65.
The sub-index will align with the CANopen Node-ID of the devices within the CANopen network, while the sub-index that matches its own CANopen Node-ID will be disregarded.
Object 1F91 h : Self starting nodes timing parameters
This object defines parameters that shall be configured to apply a determined behavior for self-starting CANopen devices Table 66 and Table 67 define the object description and entry description
The NMT master detection timeout, NMT master request delay time and node time slot shall be given in multiples of ms
Name Self-starting nodes timing parameters
Mandatory for CANopen devices supporting self-starting
Description NMT master detection timeout
Description NMT master request delay time