PreciseFlex: split setup() into connect(), initialize() and disconnect() - #1237
Closed
miikee wants to merge 1 commit into
Closed
PreciseFlex: split setup() into connect(), initialize() and disconnect()#1237miikee wants to merge 1 commit into
miikee wants to merge 1 commit into
Conversation
setup() did four things behind one name: open the socket, agree the response mode, raise high power and attach, then home. A caller that wants to read a position, or to reconnect after a controller restart, had no way to ask for part of that. connect() opens the link and sets the response mode. initialize() raises power, attaches, leaves freedrive and reads the controller's configuration. disconnect() detaches, drops power and closes the link. Neither connect nor initialize moves the arm; home() is still the only verb that sweeps it, and setup() still calls all of them in order, so existing callers are unaffected. Configuration discovery moves into _discover_configuration() and stays best-effort. Because it can fail, has_configuration says whether the arm actually read its own limits, which a caller that would rather adapt than be raised at can now check.
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
setup()did four things behind one name: open the socket, agree the responsemode, raise high power and attach, then home. A caller that wants to read a
position, or to reconnect after a controller restart, had no way to ask for
part of that.
connect()opens the link and sets the response mode.initialize()raises power, attaches, leaves freedrive, and reads thecontroller's configuration.
disconnect()detaches, drops power and closes the link.Neither
connectnorinitializemoves the arm;home()is still the onlyverb that sweeps it.
setup()calls all of them in order, so existing callersare unaffected.
Configuration discovery moves into
_discover_configuration()and staysbest-effort. Because it can fail,
has_configurationsays whether the armactually read its own limits, which a caller that would rather adapt than be
raised at can now check.
One ordering change worth flagging:
stop_freedrive_modeand configurationdiscovery now run before
home()rather than after. Freedrive off before homingis the safer order, but it is a behaviour change, not a pure refactor.
_handle_out_of_range_axesstill runs afterhome(), as before.11 new tests cover the split, including that bring-up sends no motion command.
Draft: first of five on this file. The rest are ready and will follow as this
lands, since a PR base has to be a branch in this repo.