Detecting Disconnected Nodes with Node Guarding and Heartbeat Mechanisms

[digitaldomi]

Description
I am trying to understand whether the library has built-in mechanisms to detect when a node becomes disconnected or unresponsive, and whether it can notify the master in such cases.

Case 1: Node Guarding
For each node, a Guard Time (0x100C) can be set. The NMT master sends a Node Guarding request to the node at this interval:
node.nmt.start_node_guarding(1000) # Guard Time 0x100C [ms]

Question:
Is there any timeout handling mechanism implemented in the library? Specifically, does the library provide a callback or notification when a node does not respond to node guarding requests after a certain period, such as based on the Life Time Factor (0x100D)?

Case 2: Heartbeat
When a node's heartbeat is enabled via object 0x1017 at a certain interval, it sends periodic heartbeat messages to indicate that it's still active.
network[node_id].sdo['Producer heartbeat time'].raw = 1000 # Producer Heartbeat Time 0x1017 [ms]

Question:
Does the library include a built-in mechanism to monitor heartbeat messages and inform the master if a node stops sending heartbeat messages within the expected interval (Consumer Heartbeat Time (Object x1016)? Is there a callback or notification system for heartbeat timeouts?

Environment
Library Version: 2.3.0
Python Version: 3.10.13

[acolomb]

Is there a callback or notification system for heartbeat timeouts?

Yes, here it is: https://canopen.readthedocs.io/en/latest/nmt.html#canopen.nmt.NmtMaster.add_hearbeat_callback

That can be used to build the monitoring features you describe. I don't think any more advanced functionality is implemented in the library though, that's left up to your application.

[digitaldomi]

Thank you for pointing that out. I'm aware of the heartbeat callback, but it only triggers when a heartbeat is received - not when one is missing - so it doesn’t quite fit my needs.

I've implemented a mechanism that uses the last nmt.timestamp to detect a non-responsive slave. Do you think this is a reasonable approach?

[acolomb]

Yes, that sounds reasonable. Of course the library callback only fires when a message is received, so that's one side of things. Installing a regularly scheduled timeout check is probably very specific to the rest of your application architecture, thus hard to implement in a generic way for the library. I could imagine a background timer thread checking it for convenience, but if that invokes a callback outside of your main thread context, you'll need to worry about synchronization again and then the advantage of having part of it on the library diminishes.

[digitaldomi]

Hi,

Thank you for the help!

I have a follow-up question regarding handling disconnected nodes using the nmt.timestamp functionality.

Currently, I'm using network[node_id].nmt.state to monitor the state of nodes on the bus. If a node stops responding (e.g., is removed from the bus), the nmt.state for that node remains in its last known state (e.g., Operational, Pre-Operational, or Stopped). I attempted to set the node's state to INITIALISING as an indicator of disconnection. However, I realized that setting a node's state to INITIALISING sends a reset command on the CAN bus, which is not desirable for our application.

My question is:

• Is there a way to set a node's state to INITIALISING (or any other state indicating disconnection) without sending a reset on the CAN bus?

• Alternatively, would it be necessary to create a separate list of node states in my code to track disconnected nodes independently from the library's state-tracking mechanism?

Thank you for your help!