This button brings you to the IXXAT WebpageThis is where you are at the moment IXXAT - Products, Services and Training for CAN, CANopen, DeviceNet, CAL, FlexRay, LIN, Embedded TCP/IP
Home
Introduction &
Network Structure
Communication
Device Configuration (SDO)
Process Data Exchange (PDO)
Emergency
Messages
Network
Management (NMT)
Guarding & Heartbeat
Predefined
Connection Set
Layer Setting
Services (LSS)
Device and
Application Profiles
Implementation
of CANopen
Protocol Stacks
Tools / Interfaces
Seminars / Training
Links
Downloads
Contact / Impressum



 
 
 
 

CANopen
Products:


Repeaters
Bridges & GW
PC Interfaces
Protocol Software
PLC Expansion
Analysis
Trouble-Shooting
CANopen Solutions - Basics, Profiles, Protocol Stacks, Tools, Articles ...

CANopen Basics - Network Management

CANopen network management (NMT)

In addition to providing services and protocols for the transmission of process data and the configuration of devices, the operation of a system distributed over a network requires functions for the command control of the communication state of the individual network nodes. As data transmission by CANopen devices is in many cases event-controlled, continual monitoring of the communication ability of the network nodes is also required. CANopen provides so-called "network management" services and protocols for these tasks, namely
  • control of the communication state of network nodes and
  • node monitoring.

Status of a CANopen network node and state control via NMT messages


CANopen describes the communication state of a network node in a state diagram. By sending specific CAN messages (NMT messages), the network management master can control the communication state of the other nodes (the network management slaves) of a CANopen network, i.e. it can change the state of all nodes or of an individual node by a single command.

NMT messages are transmitted with the highest priority message identifier (CAN-ID 0). The data field consists of only two bytes: the required target state is coded in the first data byte, the second data byte specifies the number of the node whose communication state is to be altered. All nodes of a network are jointly addressed with the virtual node-ID 0; in this way, for example, all nodes can be set to "Operational" state at the same time for the sake of a simultaneous start of operation.

States and changes of state





In order to enable even a partial reset of a certain node, this state is subdivided into three sub-states: "Reset-Application", "Reset-Communication" and "Initializing".
After an HW-Reset or Power-On, a node is in the "Initializing" state. After completion of the basic node initialization (e.g. host controller, CAN controller, application software, etc.), the node transmits the so-called "boot-up message" and switches itself to the "Pre-operational" state.
In the sub-state "Reset-Application", the parameters of the manufacturer-specific and of the standard device profile are reset to their Power-On values (corresponds to the last values saved). Then the node changes to the sub-state "Reset-Communication". In the sub-state "Reset-Communication", the parameters of the communication profile are reset to the Power-On values. Then the node state switches to "Initializing".

Pre-Operational


This state is primarily used for the configuration of CANopen devices. Therefore exchange of process data (via PDOs) is not possible in this state. The entries of the device object dictionaries can be accessed via "service data objects" (SDOs). By transmitting an SDO message, the object dictionary of a certain device can be modified, e.g. with a configuration tool.
In addition to communication via SDO messages, emergency, synchronization, time stamp and of course NMT control messages can also be transmitted or received in the Pre-operational state. By transmitting a "Start-Remote-Node", a node switches to the "Operational" state.

Operational


In this state, the transmission of of process data via so-called "process data objects" (PDOs) is possible.

Stopped


Except for node guarding or heartbeat messages, a node cannot transmit or receive any other messages in this state.


CANopen Device Monitoring using node guarding and heartbeat mechanisms


To ensure operability of network nodes, CANopen provides two alternatives:
  • Cyclic querying of the node state by a higher order instance, the so-called "NMT-Master" ("node guarding" principle) or
  • Automatic transmission of a "heartbeat message" by the network nodes ("heartbeat" principle).

One CAN-ID per node is required to monitor the device communication state. Low priority message identifiers with a value of 1792 + node-ID are reserved for this.

With node guarding, the NMT-master requests the other nodes in the network (referred to accordingly as NMT-slaves) with a CAN remote frame one after the other at defined intervals ("guard time") to transmit a data telegram with its current communication state (stopped, operational, pre-operational) together with a toggle-bit. If a node does not respond to the request of the NMT-master within a certain time (node life time), this is assessed as a failure of the node and indicated to the host controller of the NMT-master as a "node-guarding event". On the other hand, the NMT-slaves also monitor whether they have received a request from the NMT-master within their "life time". If such a request was absent for longer than the so-called "life time factor" of a node, the NMT-slave assumes that the NMT-master itself has failed and indicates this event as "Life guarding event" to its host controller.

With node monitoring according to the heartbeat principle, a node automatically transmits its communication state at regular intervals as evidence of its communication ability. The interval between two heartbeat messages ("heartbeat interval") of a so-called heartbeat producer is configured via the object directory entry [1017]. A value of 0 disables the heartbeat mechanism. The so-called "heartbeat consumer time" of up to 127 network nodes is given in the OD entry [1016]. This time interval describes the maximum time periode for the arrival of a heartbeat message at a monitoring node.

Nowadays, node guarding is no longer used. This might be mainly tribute to the higher bus load (due to 2 CAN messages per monitoring interval) but also to the undesirable centralisation of the crucial node healthy survey at the NMT-master.