Robot Singleton Refactor: Create hardware_control module #2232
Labels
Milestone
Comments
btmorr
added
feature
sfoster1
added a commit
that referenced
this issue
Sep 20, 2018
The hardware_control submodule is the controller of the robot's hardware. Its API can move the robot at a level of abstraction that portrays the robot as a whole, not including the labware. In this PR, the module is a stub, and not used by default. Further PRs will introduce more functionality. Closes #2232
sfoster1
added a commit
that referenced
this issue
Sep 21, 2018
The hardware_control submodule is the controller of the robot's hardware. Its API can move the robot at a level of abstraction that portrays the robot as a whole, not including the labware. In this PR, the module is a stub, and not used by default. Further PRs will introduce more functionality. Closes #2232
sfoster1
added a commit
that referenced
this issue
Sep 21, 2018
The hardware_control submodule is the controller of the robot's hardware. Its API can move the robot at a level of abstraction that portrays the robot as a whole, not including the labware. In this PR, the module is a stub, and not used by default. Further PRs will introduce more functionality. Closes #2232
sfoster1
added a commit
that referenced
this issue
Sep 24, 2018
The hardware_control submodule is the controller of the robot's hardware. Its API can move the robot at a level of abstraction that portrays the robot as a whole, not including the labware. In this PR, the module is a stub, and not used by default. Further PRs will introduce more functionality. Closes #2232
sfoster1
added a commit
that referenced
this issue
Sep 24, 2018
The hardware_control submodule is the controller of the robot's hardware. Its API can move the robot at a level of abstraction that portrays the robot as a whole, not including the labware. In this PR, the module is a stub, and not used by default. Further PRs will introduce more functionality. Closes #2232
sfoster1
added a commit
that referenced
this issue
Sep 24, 2018
The hardware_control submodule is the controller of the robot's hardware. Its API can move the robot at a level of abstraction that portrays the robot as a whole, not including the labware. In this PR, the module is a stub, and not used by default. Further PRs will introduce more functionality. Closes #2232
sanni-t
pushed a commit
that referenced
this issue
Sep 24, 2018
The hardware_control submodule is the controller of the robot's hardware. Its API can move the robot at a level of abstraction that portrays the robot as a whole, not including the labware. In this PR, the module is a stub, and not used by default Closes #2232 * fixup: More verbose names for file and thread locks * fixup: use functools.wraps in log_call decorator
b-cooper
added a commit
that referenced
this issue
Sep 26, 2018
* fix(app): Open external links in browser instead of app window (#2327) * feat(api): Remove deck calibration from reset options (#2330) Remove deck calibration from factory reset options, as deck calibration reset should not be done outside of the context of recalibration * docs(contributing): Ask Windows users to set core.autocrlf=input (#2332) Setting core.autocrlf to something that inserts carriage returns on windows means that API pushes to robots from windows will have carriage returns in the scripts in api/opentrons/resources, which prevents the robot from booting. Closes #2305 * fix(api): Update definitions for tuberacks (#2317) * fix(api): Update definitions for 15ml tuberack, 50ml tuberack, and 15/50ml tuberack to match actual Closes #2290 * Modify definitions based on practical test * feat(app): Enable autoupdate on Linux by switching to AppImage builds (#2329) Closes #2303 * chore(chore): add exception in gitattributes for our hex files (#2339) * fix(protocol-designer): fix whitescreen on deleting blowout labware (#2341) * fix unticketed bug: setting blowout to a trash-box in a step and deleting the trash box caused whitescreen *make labware dropdown blank when nonexistent labware selected * fix(api): Update the aluminum block definitions to match drawings (#2342) * fix(api): Update the aluminum block definitions to match drawings and experiments * Rename definition in shared-data to match rename in default_containers.json and fix z height * Closes #2292 * chore(release): 3.4.0 (#2338) * fix(protocol-designer): fix tiprack diagram only displaying right (#2340) Fix a small bug where the tiprack diagram in the new file modal would duplicate the diagram of the selected right pipette tiprack instead of showing both selections. * feat(api): add module firmware update endpoint (#2173) Closes #1654 Adds firmware update api methods and update server functions (for modules with old as well as new bootloader) Adds a udev rule for new bootloader Adds tests for modules and update_server endpoint * feat(protocol-designer): add "app build date" field to PD saved files (#2350) * chore(api): Cleanup unused api root level files (#2336) There were some leftovers from days of old: we don't use pip or anaconda or PyInstaller anymore. * refactor(api): invert control of system and server (#2318) Closes #2185 Separates out the previously entangled server and system functions so that opentrons.main handles system configuration while server.main only configures and runs the server. Entrypoint is switched from opentrons.server.main to opentrons.main * feat(api): Add hardware_control submodule (#2349) The hardware_control submodule is the controller of the robot's hardware. Its API can move the robot at a level of abstraction that portrays the robot as a whole, not including the labware. In this PR, the module is a stub, and not used by default Closes #2232 * fixup: More verbose names for file and thread locks * fixup: use functools.wraps in log_call decorator * ci(codecov): Fix uploading of python coverage (#2360) * fix(protocol-designer): tweak analytics copy for accuracy (#2366) Update the copy in the analytics disclaimer to accurately portray our data collection in beta.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add a new submodule called
hardware_control. This submodule should be the thing that talks to the robot hardware.This module should not be used when the software is run as it is in the robot. A human should explicitly choose to invoke its use.
The text was updated successfully, but these errors were encountered: