Ability to change the od/node ID at runtime

[belliriccardo]

Hi,
I have an application where a board's node ID needs to be changed at runtime, and quite frequently as well. I've seen in the docs for all of the network nodes, that for the id parameter: [...] Changing this after initializing the object will not have any effect.
I've tried manually going around and changing the id to the relevant object, as such:

# od: ObjectDictionary
# node: RemoteNode

od.node_id = new_id
node.id = new_id
node.sdo.rx_cobid = 0x600 + new_id
node.sdo.tx_cobid = 0x580 + new_id
# And so on; I only use SDO anyways

But, the SDO readings still fail. They only succeed if the id is correct when instantiating the od/node. Is there a way to address this without re-instantiating a RemoteNode every time the id of a node is changed? Am I missing something?

[belliriccardo]

Update: I can see with busmaster that the request is wrongly formed (0x80 instead of 0x40) and that the board responded, but instead of getting the value back I get "No SDO response received"

Here is the full traceback:

Transfer aborted by client with code 0x05040000
Traceback (most recent call last):
  File "C:\DATA\program\.venv\Lib\site-packages\canopen\sdo\client.py", line 67, in read_response
    response = self.responses.get(
               ^^^^^^^^^^^^^^^^^^^
  File "c:\Users\riccardo.b\AppData\Local\Programs\Python\Python312\Lib\queue.py", line 179, in get
    raise Empty
_queue.Empty

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\DATA\program\src\canopen.py", line 221, in read_odvar
    value = var.raw
            ^^^^^^^
  File "C:\DATA\program\.venv\Lib\site-packages\canopen\variable.py", line 77, in raw
    value = self.od.decode_raw(self.data)
                               ^^^^^^^^^
  File "C:\DATA\program\.venv\Lib\site-packages\canopen\variable.py", line 41, in data
    return self.get_data()
           ^^^^^^^^^^^^^^^
  File "C:\DATA\program\.venv\Lib\site-packages\canopen\sdo\base.py", line 147, in get_data
    return self.sdo_node.upload(self.od.index, self.od.subindex)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\DATA\program\.venv\Lib\site-packages\canopen\sdo\client.py", line 118, in upload
    with self.open(index, subindex, buffering=0) as fp:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\DATA\program\.venv\Lib\site-packages\canopen\sdo\client.py", line 206, in open
    raw_stream = ReadableStream(self, index, subindex)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\DATA\program\.venv\Lib\site-packages\canopen\sdo\client.py", line 252, in __init__
    response = sdo_client.request_response(request)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\DATA\program\.venv\Lib\site-packages\canopen\sdo\client.py", line 86, in request_response
    return self.read_response()
           ^^^^^^^^^^^^^^^^^^^^
  File "C:\DATA\program\.venv\Lib\site-packages\canopen\sdo\client.py", line 70, in read_response
    raise SdoCommunicationError("No SDO response received")
canopen.sdo.exceptions.SdoCommunicationError: No SDO response received

[acolomb]

I believe it has to do with the network subscriptions. Setting up a node object includes several calls to Network.subscribe() in .associate_network(). Those won't be called again when you just set a different node ID attribute, as the description indicates.

The better way to handle this will be to create a new LocalNode or RemoteNode object with the new ID and add that to the network. Pass the previous object's node.object_dictionary attribute to the constructor to retain its state. For a LocalNode, also the .data_store attribute. Then remove the old object from the Network and destroy it.

A shortcut might be to call remove_network() and then again associate_network() on the existing node object, while making your ID adjustments in between those calls. But there's no guarantee that this will keep working, as our internal assumption is that the node ID does not change. You might need to add other workarounds when we decide to depend on that fact in other code parts later.