Network management (NMT)
The CANopen network management is based on a master/slave approach. The device with NMT master functionality controls the CANopen NMT slave devices. Each NMT slaves can be in one of three static states:
- Pre-operational: All CANopen services can be used, except PDO services
- Operational: All CANopen services can be used
- Stopped: No CANopen services can be used, except NMT and Heartbeat
There are additional temporarily states, which the device is transits automatically after power-on and after be reset. The shown state diagram provides details on the possible state transitions. Those transitions are commended by the NMT master or device internally by the application.
The NMT commands by the NMT master devices are confirmed on the application program level by means of the Heartbeat message. The NMT command message is a two-byte message containing in one byte the command and in the other one the addressed node-ID. A node-ID of “0” indicates a broadcast command meaning that all nodes shall perform the command. It is mapped to the CAN data frame with CAN-ID “0”, which is the highest prior one. This makes sense, because what is more important than a command of the NMT master. The above-mentioned confirmation is a one-byte message providing the current state (pre-operational, operational, or stopped) of the related NMT slave device. It is mapped depending on the node-ID of the transmitting device to CAN data frame with a CAN-ID of 80016 plus node-ID. The Heartbeat message is sent periodically with the user-configurable heartbeat-producer-time given in the object dictionary.
After power-on, the CANopen NMT slave transits automatically into the NMT pre-operational state and waits to be configured optionally and to be started by the NMT master device. There is also the possibility to configure an NMT slave device to be self-starting. This is in some CANopen applications needed. There are two reset commands: one just resets the communication parameters to the default or the configured values; the other resets the communication and the profile parameters. After the reset procedure, the NMT slave device transits automatically to the NMT pre-operation state.
The NMT stopped state can be used to stop a device communicating SDO and PDO messages. It just accepts the NMT message and produces the Heartbeat message. In some cases, it is desired that the devices is not transmitting any message. To achieve this, the heartbeat-producer-time in the object dictionary needs to be configured to “0”.
Since many years, the legacy option to remotely request the Heartbeat message by means of a CAN remote frame (so-called Node/Life guarding) is not more recommended. This approach also used a life-timer implemented in each NMT slave device. When it expired without receiving the appropriate CAN remote frame from the NMT master device, the NMT slave considered that the NMT master device is not more available and behaved as programmed for this case.
NMT flying master
Because in mission-critical applications a single entity is not acceptable, CiA 302-3 specifies the NMT flying master approach. There are several services provided, which allow that a second NMT master capable device functions as NMT master device, when the original NMT master is not available. When the original NMT master comes back, it requests to become the active NMT master. This NMT flying master functionality is used in maritime electronics as well as in medical devices. Also subsea trees on the ocean ground implements redundant NMT master devices using the NMT flying master protocols.