There are a few lines executed in the update-loop that are rather part of the activation procedure

[destogl]

Resetting and starting of nodes is rather a part of the activation process, so it shouldn't be done/checked all the time in the update loop. Changing this would lead to clearer code and behavior, but it has some strong drawbacks:

1. Needs error management inside HW interface. ros2_control supports that (see this PR), but then also all the controllers get deactivated – and they have to manually activated again.
2. The first point clearly disturbs the prototyping and makes it much harder is someone doesn't understand all the internal mechanisms from ros2_control.
3. There is currently not possibility to automatically re-activate hardware and controllers which probably is desired scenario is many applications to handle bus errors better, e.g., bus errors caused by use of non-realtime kernel.

ros2_canopen/canopen_ros2_control/src/canopen_system.cpp

Lines 270 to 280 in 1ac8251

	// reset node nmt
	if (it->second.nmt_state.reset_command())
	{
	it->second.nmt_state.reset_fbk = static_cast<double>(proxy_driver->reset_node_nmt_command());
	}
	// start nmt
	if (it->second.nmt_state.start_command())
	{
	it->second.nmt_state.start_fbk = static_cast<double>(proxy_driver->start_node_nmt_command());
	}

P.S. I will also extend this in the future with possible solutions when different options are tested in real-world scenarios.

[hellantos]

@destogl any updates here or is this closable?

[destogl]

I didn't do enough tests yet. So I would keep this open, but it will take time to get it fixed / closed.