feat(api): Add G Code for pipette config in driver #3388
Merged
Conversation
This file contains 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
Codecov Report
@@ Coverage Diff @@
## edge #3388 +/- ##
==========================================
+ Coverage 52.57% 52.59% +0.01%
==========================================
Files 775 775
Lines 22905 22980 +75
==========================================
+ Hits 12043 12086 +43
- Misses 10862 10894 +32
Continue to review full report at Codecov.
|
sfoster1
requested changes
Apr 29, 2019
| @@ -267,6 +267,16 @@ def get_lights(self) -> Dict[str, bool]: | |||
| self._config.instrument_offset[mount.name.lower()], | |||
| instrument_data['id']) | |||
| self._attached_instruments[mount] = p | |||
| if 'v2' in model: | |||
There was a problem hiding this comment.
What happens if you replace a v2 with a v1.x? Don't we need to reset the steps per mm?
sfoster1
requested changes
Apr 29, 2019
| self._driver.update_steps_per_mm({axis: 2133.33}) | ||
| # TODO(LC25-4-2019): Modify configs to update to as | ||
| # testing informs better values | ||
| self._driver.update_pipette_config(axis, {'home': 172.15}) |
There was a problem hiding this comment.
here we need to update the pipette config back to defaults for non-v2 models (or take the time now to add this data to the model configs)
| expected['Z'] = 450 | ||
| assert smoothie.steps_per_mm == expected | ||
|
|
||
|
|
||
| def test_set_acceleration(smoothie, monkeypatch): | ||
| from opentrons.drivers import serial_communication | ||
| from opentrons.drivers.smoothie_drivers import driver_3_0 |
There was a problem hiding this comment.
We should add tests to make sure that the proper gcodes are sent for the 365s, and also that the proper driver methods are called upon pipette detection
- We need to set the max travel for pipette plunger axes appropriately for the pipette type so the smoothie knows the correct distance to home (fixes homing error) - we have to recalculate the axis maximum every time in mover since it might change now based on what kind of pipette is loaded (this takes 1ms or so) - the smoothie firmware file had one more character in its name than stored internally so it would always think it had to update
sfoster1
approved these changes
May 2, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
overview
Closes #3324 and closes #3323. This will allow for configurations to be modified at run time/upon detection of a different pipette type.
changelog
v2update_pipette_configreview requests
M365.*gcodes without physically testing on the robot, any ideas?