mcous
commented
2 years ago Thanks for the report! Which tube rack definition are you observing this behavior with? A short protocol that reproduces this behavior would also be useful.
Open kelleyjbrady opened 2 years ago
mcous
commented
2 years ago Thanks for the report! Which tube rack definition are you observing this behavior with? A short protocol that reproduces this behavior would also be useful.
kelleyjbrady
commented
2 years ago The mother rack is a opentrons_24_tuberack_eppendorf_1.5ml_safelock_snapcap, the daughter is a opentrons_96_aluminumblock_generic_pcr_strip_200ul sitting on a temperature module gen2. Unfortunately I need all of my robots functioning, so I will not be able to re-upgrade to 5.0 or 5.0.1 in order to reproduce the error, but I will make a toy version of the protocol in question tomorrow morning -- sorry I'm on PST and need to get home for the day.
UfieA
commented
2 years ago Hi Kelley, we observed the same issue at our two systems at two different locations, and no success by downgrading to 5.0.1 to 5.0.0 to 4.7.0 but you mentioned downgrading to 4.6.2 resolves the issue? We can't run either jason or py generated profiles, it simply does not save the offsets for the labware. You see this if you switch from one profile to other and also if you turn off the OT-2 or logout of the computer.
mcous
commented
2 years ago There have been no (intentional) changes to motion planning or labware definitions in the 5.x release. In terms of actual protocol logic, the primary change is that 5.x sources a labware's offset vector from the Labware Position Check wizard, whereas 4.x sourced that offset vector from the old "labware calibration" flow, which saved offsets to disk by labware definition.
I think the most likely scenario here is that the persisted offset values you were using in 4.x had been entered to account for some other issue, and moving to 5.x and having to re-do the offset measurement exposed that issue again. Issues that could cause this:
As a starting point, I would compare the offset vector you have saved in 4.x with the measured offset vector from Labware Position Check in 5.x
UfieA
commented
2 years ago Hi Mike,
The system was running on 4.7 with no issues whatsoever. App prompted to upgrade to 5.0.1 and we foolishly apply the update and this is where all the issues started.
You can run the system as long as you recalibrate all the labware each time , do not get out of the App, turnoff the system or the computer and you do not have any other profiles to use otherwise all these settings not saved. I do not see how this is feasible in routine lab work where each time someone has to re adjust the labware offset settings. Specifically if this is a clinical lab where everything is strictly controlled.
We even have opentron written python profiles they do no longer work with this app 5.0 and 5.0.1.
We also tried to revert back to 4.7 thinking this will work and this also failed because it does not allow us to open any profile.
I really would like to hear if 4.6 resolves this issue until you guys find out working solution but most importantly, you should not release software updates unless if it is diligently checked before release considering our systems are used in clinical setting.
Ufie
From: Mike Cousins @.> Sent: Wednesday, March 2, 2022 9:28 AM To: Opentrons/opentrons @.> Cc: UfieA @.>; Comment @.> Subject: [Customer Service] Re: [Opentrons/opentrons] Robot does not keep a consistent 'top of tube' definition in 5.0+ (Issue #9602)
There have been no (intentional) changes to motion planning or labware definitions in the 5.x release. In terms of actual protocol logic, the primary change is that 5.x sources a labware's offset vector from the Labware Position Check wizard, whereas 4.x sourced that offset vector from the old "labware calibration" flow, which saved offsets to disk by labware definition.
I think the most likely scenario here is that the persisted offset values you were using in 4.x had been entered to account for some other issue, and moving to 5.x and having to re-do the offset measurement exposed that issue again. Issues that could cause this:
As a starting point, I would compare the offset vector you have saved in 4.x with the measured offset vector from Labware Position Check in 5.x
— Reply to this email directly, view it on GitHub https://github.com/Opentrons/opentrons/issues/9602#issuecomment-1056990432 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AYA4D6463TGTAA4I5CIC4GLU553IZANCNFSM5PVX6BJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you commented. https://github.com/notifications/beacon/AYA4D6ZJPBD6JZJJZDTC5FDU553IZA5CNFSM5PVX6BJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOH4AGJYA.gif Message ID: @. @.> >
mcous
commented
2 years ago @UfieA please contact Opentrons support, they are better equipped to handle your issue than this bug tracker. After you downgrade the Opentrons App to 4.7, you must subsequently downgrade the OT-2 software, too from the robot's settings page. If you do not downgrade both your app and robot software, you won't be able to open and run protocols.
You can also disable the app's update notifications, which I would recommend in a clinical setting.
I'm going to hide your GitHub comment above since it's off topic from this original issue about tube-rack movement issues. Please feel free to continue this discussion in #9603.
UfieA
commented
2 years ago Hi Mike,
We were talking to support throughout this entire process and they were of no help thus far, so we decided to go to the bug page to see if anyone else was having issues, and wanted to let other people know what issues we are having in the event that they may relate.
We downgraded both the robot and the app software per the opentrons support recommendations each time. We spent two full days at a client's lab that is nowhere close to us to try to resolve these issues, and they are now unable to use their typing kits in the meantime so we are just looking for a way to resolve this.
Thank you for your help in the meantime, Mike.
Have a great rest of your day, Maggie and Ufie
On Wed, Mar 2, 2022 at 9:58 AM Mike Cousins @.***> wrote:
@UfieA https://github.com/UfieA please contact Opentrons support, they are better equipped to handle your issue than this bug tracker. After you downgrade the Opentrons App to 4.7, you must subsequently downgrade the OT-2 software, too from the robot's settings page. If you do not downgrade both your app and robot software, you won't be able to open and run protocols.
You can also disable the app's update notifications https://support.opentrons.com/en/articles/5221924-features-of-the-opentrons-app, which I would recommend in a clinical setting.
I'm going to hide your GitHub comment above since it's off topic from this original issue about tube-rack movement issues.
— Reply to this email directly, view it on GitHub https://github.com/Opentrons/opentrons/issues/9602#issuecomment-1057025301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYA4D66HJVB2A3DA3C2NUILU5562BANCNFSM5PVX6BJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
--
Maggie D'Aprix
Application Specialist
Work. +1 (888) 352-2196 ext: 103
Direct: +1 (315) 381-5599
Fax. +1 (315) 381-5603
@.***
www.inno-train.com
Overview
On OT software&robot v5.0+, freshly calibrated (deck and all pipette parameters) before the run: Run a dispensing protocol where, in my case, a
p300_single_gen2aspirates from a mother tube, then dispenses into a/some daughter tube(s).Current behavior
Robot moves into position to perform the first aspiration -- moving to the mother tube with sufficient height under the currently loaded tip such that the tip does not collide with the outside of the mother tube (ie. it comes in over the tube, then goes down into it). The robot then aspirates from the tube, but as it attempts to move to the daughter tube it does not raise the tip to a sufficient height to prevent the tip from colliding with the inside wall of the mother tube (even though the protocol presumably 'knows' how tall the tube is or the tip would have collided with the outside of the tip as the robot got into position to aspirate). If you do not put the mother tube into the rack at the start of the process and let the robot run as if it had aspirated, then dispensed and then, without getting your hand stabbed, you quickly load a mother tube onto the rack, it will crash the tip into the outside wall of the tube when it attempts to move back to perform the next mother tube aspiration (even thought it was able to do exactly such a move in the very first step).
Expected behavior
The robot should not collide with properly calibrated tubes. Downgrading to 4.6.2 resolves the issue.