-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename RemoteNode.load_configuration() #480
Comments
IMO, |
I agree it's not a perfect name now, but frankly I never noticed the function before the recent PR and it's just a convenience function for a loop that could easily be copied to application code. I wonder who would even want to touch every possible (writable) object in a device? They should have sensible default values and a "restore defaults" function, so only setting necessary adjustments from that base is the more usual approach AFAICT. I'd say let's not open any cans of worms regarding deprecation and renaming over this. With a better docstring explaining what it does, the API can stay as it is. |
FTR, |
Since the newly updated docs use the CANopen-esque "download" word, this makes sense. |
That might not be the best coding style for real applications though, but more to serve as an example. But applications and network requirements can vary widely, so if the API user wants to flood the bus with SDOs in a script, then we have a convenience flooder method for sure. I lean toward lean, i.e. configuring devices once during commissioning, then saving, and not worry about all parameters during each startup of the whole machine. That's probably why I never even looked for such a "download everything" method. |
What the author of PR #405 wants is not "download everything" to the node, but a way to configure/setup the PDO object from the loaded OD. So we're back at not really knowing what the actual use cases are for |
The # L52: This _downloads_ the PDO configuration to the remote node and assumes
# a device which have the ability to set the PDO configuration
node.load_configuration()
# L69: This _uploads_ the PDO configuration from the remote node
node.tpdo.read()
# L82 This _uploads_ the PDO configuration from the remote node
node.rpdo.read() If the remote PDO configuration in the remote node is blank at start-up the If the remote node has a static PDO configuration and with a complete OD that describes the PDO, everything may be done without any SDO IO: node = RemoteNode(..., object_dictionary=something)
node.tpdo.read(from_od=True)
node.rpd.read(from_od=True) edit: Perhaps this is a separate issue about the example and not the rename, thou :P |
Yes, sorry for distracting you with the example. But that borderlines a discussion I just started: I'm suggesting to use Diátaxis as a north star for the |
Yes, but we agreed that it was simply the wrong method. For that use, Your assessment of the example code is correct. The only plausible reason for doing Normally, changes to the PDO config should go through the library's PDO methods, including |
We probably overlooked #427, where applying the PDO related values from a DCF is actually made functional in the first place. It uses the PDO classes to apply the provided values and skips the usual SDO transfer. And it fixes But we will need to adjust the example accordingly, which is confusing / inefficient as @sveinse has pointed out. EDIT: Created #496 to track the issues regarding the example code. |
Since we're spawning of many sub-discussions from this: I read we have consensus that we don't really see the need to reaname the |
The
RemoteNode.load_configuration()
isn't named in a good way. Ref #405 (comment) it should be named.set_configuration()
or perhapsdownload_configuration()
to follow CANopen nomenclature.If we rename the method, we should keep the old method name to not break the API, however with a deprecation warning, see #479
The text was updated successfully, but these errors were encountered: