-
Notifications
You must be signed in to change notification settings - Fork 178
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
API: Update Module Firmware from Filesystem #4575
Labels
Milestone
Comments
b-cooper
added
feature
Ticket is a feature request / PR introduces a feature
api
Affects the `api` project
labels
Dec 9, 2019
2 tasks
b-cooper
added a commit
that referenced
this issue
Jan 24, 2020
Creates a generalized approach for determining whether an attached module is capable of being updated, based on the module firmware artifacts bundled in the filesystem. In addition to adding this functionality, it includes a couple of refactors to dedupe common module subclass responsibilities. In debugging this branch, I also included some loop level error handling so exceptions in asyncio tasks (e.g. module instance creation) don't get swallowed. re #4575
b-cooper
added a commit
that referenced
this issue
Jan 28, 2020
…4856) Creates a generalized approach for determining whether an attached module is capable of being updated, based on the module firmware artifacts bundled in the filesystem. In addition to adding this functionality, it includes a couple of refactors to dedupe common module subclass responsibilities. In debugging this branch, I also included some loop level error handling so exceptions in asyncio tasks (e.g. module instance creation) don't get swallowed. re #4575
5 tasks
b-cooper
added a commit
that referenced
this issue
Feb 5, 2020
…sed paths Handle the case of a user attempting to update a module with an unsupported bootloader. Fix regression that caused thermocyclers to fail to enter programming mode. Remove unused code supporting old module update pathways. re #4575
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
overview
Now that #4441 is in, the hardware controller (via context) should always be aware of physically connected hardware modules. We need to be able to do a couple of new things to wire up the new module firmware update flow.
Compare the version of a connected module's firmware, to the version present in the file system
*NOTE: Requires distribute opentrons module firmware as a package buildroot#58 to be completed, in order to
have access to module firmware files inside the robot software.
Serve a GET endpoint that reports whether there is an available update (calculated in step 1), for a given module serial number.
Serve a POST endpoint that attempts to execute the firmware update available for a given module by its serial number.
The corresponding Run App behavior is outlined in #4576
The text was updated successfully, but these errors were encountered: