René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"examples/simple_ds402_node.py uses contradictory PDO mapping patterns ","articleBody":"The example uses the `RemoteNode.load_configuration()` API to send `ParameterValue` settings given in the sample EDS file to the device.  This used to work in conjunction with `PdoBase.read()` to synchronize the locally cached PDO configuration and mapping info.  Calling that method (on any PDO) was therefore not really necessary, as it was implied as a final step in `load_configuration()`.\r\n\r\nBut #427 changed this and made `load_configuration()` apply the PDO configuration through calls to `PdoBase.save()` instead.  Thus the need to read it back was eliminated.\r\n\r\nIn any case, the example goes on to call `BaseNode402.setup_402_state_machine()`, which then reads back the PDO configuration again.  Here it would help to pass `read_pdos=False` since we know that the configuration was just saved, skipping the unnecessary upload.\r\n\r\nThat convenience method also checks whether needed values like the status and control words are configured in the respective PDOs.  Which should succeed because of the initialization values in the sample EDS (haven't tested).\r\n\r\nBut then the example code continues with re-mapping the PDOs, which (probably?) invalidates the `rpdo_pointers` and `tpdo_pointers` entries pointing at the previous PDO mapping's `PdoVariable` objects.  This should be done before `setup_402_state_machine()` to avoid this error.  In addition, the example first uses `node.tpdo.read()` and `node.rpdo.read()` before adjusting the mappings, which, again, is unnecessary after `load_configuration()`.\r\n\r\nFurthermore, before the PDO re-mapping, it tries to change the `node.state` attribute, but there is no prior change of `node.nmt.state = 'OPERATIONAL'`, thus the exchanges of control and status words cannot work.  There is a fallback to SDO implemented if no PDO maps the required objects, but that is not triggered because they are in fact mapped.  The problem is that in PRE-OPERATIONAL state, the node's PDOs simply do not function.  Re-mapping them after the previous `PdoVariable` objects have been cached (see above) doesn't make this any better.\r\n\r\nThese are some observations from trying to understand the sample code, showing that it is mostly broken for actual usage and suggests wrong or inefficient patterns of the library API usage.  There may be more problems hidden, which could be revealed after testing with actual hardware.  Maybe that was done at some point, but probably not after the library API has evolved and some functionality (especially regarding profile CiA402) moved around.\r\n\r\nWe should discuss how to make this example actually useful again, or at the very minimum, document that it serves only as a demonstration of the API and will not work with real hardware unless the user takes care of the issues with their hopefully firm CANopen background themselves.","author":{"url":"https://github.com/acolomb","@type":"Person","name":"acolomb"},"datePublished":"2024-07-04T21:32:25.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/496/canopen/issues/496"}