feat(api): implement mix() parameters aspirate_delay and dispense_delay#18000
Merged
feat(api): implement mix() parameters aspirate_delay and dispense_delay#18000
aspirate_delay and dispense_delay#18000Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## edge #18000 +/- ##
=======================================
Coverage 24.44% 24.44%
=======================================
Files 2956 2956
Lines 228425 228425
Branches 19032 19032
=======================================
Hits 55843 55843
Misses 172570 172570
Partials 12 12
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
jerader
reviewed
Apr 9, 2025
Collaborator
jerader
left a comment
jerader
left a comment
There was a problem hiding this comment.
this is great, getting closer to always emitting python mix() when a mix step is added.
ncdiehl11
approved these changes
Apr 10, 2025
Collaborator
ncdiehl11
left a comment
ncdiehl11
left a comment
There was a problem hiding this comment.
This is looking good! Thank you for the details about why we need to manually publish a message to the broker. Tested simulation and the output looks as expected (snipped below). Approving with the caveat that a robot server dev should put eyes on this :)
Contributor
Author
Oh wow, thanks for testing it in the app! |
sanni-t
approved these changes
Apr 22, 2025
Member
sanni-t
left a comment
sanni-t
left a comment
There was a problem hiding this comment.
LGTM! Just some small comments
Comment on lines
+575
to
+579
| # protocol_api_old/test_context.py does not allow push_out at all, even if | ||
| # it's set to None, so we have to hide the argument to make the test pass. | ||
| # I don't know if the test is even valid, but I'm afraid to change the test. | ||
| dispense_kwargs = {"push_out": push_out} if push_out is not None else {} | ||
| self.dispense(volume, None, rate, **dispense_kwargs) |
Member
There was a problem hiding this comment.
Hmm, ya looks like we're raising an error if push_out is used in dispense in API versions < 2.15. The old context tests are for < v2.15.
I guess another way to write this would have been to skip the push_out based on API version but this works too. Maybe you can update the comment to mention that legacy context based dispense doesn't take a push_out arg and hence you have to do this.
Comment on lines
+1611
to
+1618
| mock_instrument_core.aspirate( | ||
| input_location, | ||
| mock_well._core, | ||
| 10.0, | ||
| 1, | ||
| 4.56, | ||
| True, | ||
| None, |
Member
There was a problem hiding this comment.
A soft opinion- it's better to use kw args when calling any functions with more than 2 args, It gets difficult to read through the calls quickly otherwise.
ddcc4
added a commit
that referenced
this pull request
May 16, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.
ddcc4
added a commit
that referenced
this pull request
May 16, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.
ddcc4
added a commit
that referenced
this pull request
May 16, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.
ddcc4
added a commit
that referenced
this pull request
May 16, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.
ddcc4
added a commit
that referenced
this pull request
May 16, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.
ddcc4
added a commit
that referenced
this pull request
May 16, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.
ddcc4
added a commit
that referenced
this pull request
May 17, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.
ddcc4
added a commit
that referenced
this pull request
May 17, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.
ddcc4
added a commit
that referenced
this pull request
May 17, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.
ddcc4
added a commit
that referenced
this pull request
May 17, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 17, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 17, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 17, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 17, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 17, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 19, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 19, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 19, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 20, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 20, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 22, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 23, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 24, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 24, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 29, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 29, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
ddcc4
added a commit
that referenced
this pull request
May 29, 2025
…delay` (#18000) # Overview In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI `mix()` call, which means that we can't translate a PD Mix step into a PAPI `mix()` call. This PR introduces the parameters `aspirate_delay` and `dispense_delay` to the `InstrumentContext.mix()` function. The new parameters are gated to API version 2.24 and above. AUTH-1366 ## Test Plan and Hands on Testing I added tests to demonstrate that this implementation emits the correct calls to `delay()` when the caller requests a delay in the `mix()`. This is what the output looks like in `simulate`: ``` Mixing 2 times with a volume of 20.0 ul Aspirating 20.0 uL from C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec Delaying for 0 minutes and 2.5 seconds Dispensing 20.0 uL into C2 of (Retired) Armadillo 96 Well Plate 200 µL PCR Full Skirt on slot A2 at 716.0 uL/sec ... ``` ## Review requests `InstrumentContext.mix()` calls `InstrumentContext.aspirate()` and `InstrumentContext.dispense()` to implement the mix, which is nice because the public `aspirate()` and `dispense()` functions handle things like publishing messages for the simulator. Ideally, we would also call the public `delay()` function for the delay. But the `delay()` function is in `ProtocolContext`, and `InstrumentContext` doesn't have access to that. We only have access to the `ProtocolCore`, so we have to publish messages to the simulator manually. I ended up refactoring the code of `mix()` a bit because it was going to get too repetitive and nested with the delays and `publish_context()` messages added. ## Risk assessment Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way. (cherry picked from commit 5012148)
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
4 participants
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
In PD, you can specify a delay after each aspirate and dispense in a Mix step. There is no way to specify a delay in the PAPI
mix()call, which means that we can't translate a PD Mix step into a PAPImix()call.This PR introduces the parameters
aspirate_delayanddispense_delayto theInstrumentContext.mix()function. The new parameters are gated to API version 2.24 and above. AUTH-1366Test Plan and Hands on Testing
I added tests to demonstrate that this implementation emits the correct calls to
delay()when the caller requests a delay in themix().This is what the output looks like in
simulate:Review requests
InstrumentContext.mix()callsInstrumentContext.aspirate()andInstrumentContext.dispense()to implement the mix, which is nice because the publicaspirate()anddispense()functions handle things like publishing messages for the simulator.Ideally, we would also call the public
delay()function for the delay. But thedelay()function is inProtocolContext, andInstrumentContextdoesn't have access to that. We only have access to theProtocolCore, so we have to publish messages to the simulator manually.I ended up refactoring the code of
mix()a bit because it was going to get too repetitive and nested with the delays andpublish_context()messages added.Risk assessment
Should be low. The new parameters are version-gated. The main risk is that we release this, and then decide that we don't want to change the public API this way.