Discard tip issues on STARlet

I’m having a few issues with the discard tip function in PLR.

8 Channel
When running discard_tips() with 50uL tips, the tip ends are crushed during the discard. Is there a way to set the height higher or reteach where it discards the tips?


96 CO-RE Head
When running discard_tips96(), it seems like it does not know where the trash is. I checked that I am using the correct deck. How can I correct the trash location?

1 Like

this is because the 50uL tips are very soft and discard (on Hamilton) works by moving the tip down until there is resistance. You can override this using the drop_method backend kwarg:

from pylabrobot.resources.hamilton.tip_creators import TipDropMethod
await lh.discard_tips(
  use_channels=[0],
  drop_method=TipDropMethod.DROP)

The issue with this is that the tips will be shot down quite violently and bounce on the trash area (where they get pushed down usually), sometimes coming back to the tack. Unfortunately, the arm doesn’t reach further right (into trash area) so shooting directly into the trash is not possible.

This seems fundamentally broken with 50uL tips on the Hamilton. Perhaps worth asking on labautomation.io how people deal with it?

Alternatively, call return_tips and just trash them manually after a run.

for the 96 head: all stars with a 96 head i have seen had a trash area in that location, but yours apparently does not. I believe the reason is typically a 96 head can’t reach the ‘regular’ trash, but yours might. If you turn the robot off and move it over, do you think it can reach?

This might be an issue with the picture I took. There is a trash where I would expect it for a STAR and I previously was sending tips to the trash using discard_tips96(). It seems like something I did recently is causing it to not know where the trash is… Could there be a something I am incorrectly importing?

I run

from pylabrobot.liquid_handling import LiquidHandler
from pylabrobot.liquid_handling.backends import STAR
from pylabrobot.resources.hamilton import STARLetDeck
backend = STAR()
lh = LiquidHandler(backend=backend, deck=STARLetDeck())

and then get

lh.summary()

Rail  Resource                      Type           Coordinates (mm)
=================================================================================
(-6)  ├── trash_core96              Trash          (-58.200, 106.000, 229.000)
      │
(31)  ├── teaching_carrier          Resource       (775.000, 051.800, 100.000)
      │   ├── teaching_tip_rack     TipRack        (780.900, 461.100, 100.000)
      │
(32)  ├── trash                     Trash          (800.000, 190.600, 137.100)

FYI this doesn’t happen with 50ul tips in Hamilton Venus. Not sure what’s going on there. We use 1000s of 50ul tips a week and don’t get that on any of our 10 instruments

1 Like

would you mind sharing a line from the firmware log where you discard 50uL tips to trash? curious to see if there is a difference

@rickwierenga - how do I get the firmware log?

@cwehrhan - I’m using compatible generic tips so it is unclear to me if it is an issue with the tips or the PLR method

HxUsbComm********.trc in C:\Program Files (x86)\Hamilton\LogFiles. You’re looking for the line that says C0TRxxx

I just did it in sim on Venus, think it should behave the same, can confirm in office next week:

C0TRid0214xp13400&yp4050 3782 3514 3246 2978 2710 2442 2175tp1970tz1870th2450te2450tm1&ti0

1 Like

smh sorry I meant C0ER for discard tips with 96 head :man_facepalming:

Oh sorry thought we were trouble shooting the crushed 50ul tips on the the 1000ul independent channels? I’m also not familiar with running any non-Hamilton made tips.

In Venus, all tips on the independent 1000ul channels are discarded with a “dead mans fall” where they are ejected right above the waste bar, but just enough so they are still slightly seated on the channels, then the whole arm moves in the negative x direction where the tip over into the waste (the Deadman fall portion).

1 Like

I am running PLR through a raspberry pi and I could not find a log file there. So this is from a log file from VENUS on Windows where I ran a weekly maintenance check.

Below is what I found in the most recent log file for C0TRxxx

< 09:05:10.123 8AF#8000#00: C0TRid0298xp07862&yp5290 5200 5110 5020 4930 4840 4750 4660tp1330tz1230th2450te2450tm1&ti0
> 09:05:17.050 8AF#8000#00: C0TRid0298er00/00kz397 354 322 457 366 388 368 415vz400 358 336 457 368 389 373 417


---
< 09:05:56.862 8AF#8000#00: C0TRid0337xp07862&yp5290 5200 5110 5020 4930 4840 4750 4660tp1330tz1230th2450te2450tm1&ti0
> 09:06:03.819 8AF#8000#00: C0TRid0337er00/00kz397 354 322 457 366 388 368 415vz400 358 326 461 370 390 372 419

----

< 09:10:59.211 8AF#8000#00: C0TRid0281xp07862&yp5290 5200 5110 5020 4930 4840 4750 4660tp1330tz1230th2450te2450tm1&ti0
> 09:11:06.140 8AF#8000#00: C0TRid0281er00/00kz397 354 322 457 366 388 368 415vz401 358 327 461 370 392 372 419


---


< 09:11:45.960 8AF#8000#00: C0TRid0320xp07862&yp5290 5200 5110 5020 4930 4840 4750 4660tp1330tz1230th2450te2450tm1&ti0
> 09:11:52.885 8AF#8000#00: C0TRid0320er00/00kz397 354 322 457 366 388 368 415vz401 358 326 461 370 392 372 419

---
< 09:13:30.827 8AF#8000#00: C0TRid0378xp07862&yp5290 5200 5110 5020 4930 4840 4750 4660tp1330tz1230th2450te2450tm1&ti0
> 09:13:38.853 8AF#8000#00: C0TRid0378er00/00kz397 354 322 457 366 388 368 415vz401 358 326 461 370 392 372 419

I can’t find any instances of C0ER

1 Like

@rickwierenga I was searching through some of the code/documentation to see if there is a way I can reassign the coordinates for the 96 trash and I saw this commit about fixing the 96 head trash. What was this change?

that is when i was fixing it for @mackenzie (unfortunately part this thread is in private email)

is it possible there are two trash location configurations??

How did you define the waste originally? FYI Hamilton Venus 4.5 and Venus 6.0 have different waste positions, but in physical reality they should be the same. So maybe you grabbed new vs old definition virtual definition when making the PyLabRobot position.

I’m not sure why they decided to change things around, as in 4.5 things seemed fine

I think the answer is yes but I am not 100% sure. We realized on VENUS there was a difference for the trash96 coordinates if it used the slide chute or the external waste. We don’t have the slide chute but the CO-RE head would go to where it thought the chute was until we reformatted the deck in that protocol. Maybe it is a similar thing here?

1 Like

i just discarded some 50uL tips and they didn’t bend. Perhaps if they have been used extensively / in acidic liquids they become more fragile? the way discard works is the channel moves down until resistance is found, then gently pushes over the tip to prevent aerosols. ejecting tips is possible, but not suggested because it has a higher risk of creating aerosols.

firmware commands match

Looking around some more and asking our mutual friends at Nugget: looks like the 50uL tip crunching issue is specific to the generic tips I bought. They are slightly longer and narrower than the Hamilton tips. I bought some Hamilton tips to test so we’ll see if its the tips or the robot causing the issue.

3 Likes

can be addressed in plr!

for asp/disp: yes (important to get this right, otherwise the robot will move tips too high/low in the containers and when you change to different 50uL tips your protocol breaks)

for discard: no, since it uses z-touch probing to find the trash location

i’ve found that offsetting the trash can fix this tip crushing issue on longer 50ul alinity pipette tips, perhaps by increasing the ‘seek height’ of the z touch probing

2 Likes