Remove Tecan parameter off x/y

[nedru004]

Another question I have in regards to off_x and off_y. Reference #552

For off_x, this should be easy to remove and just adjust the coordinates of the resources. There are no overhangs that I can see in -x direction, however, I found one trough carrier that has an overhang in the +x direction.

As for off_y, that is a bit more complicated. Tecan homes to the back left of the machine, which makes the front of the machine a larger coordinate value. This is opposite to how I visualize it. How does Hamilton work?

off_y is needed since each carrier is not the same size (see image below comparing plate carrier vs trough carrier).

Here is the code for placing a resource on the deck. It take 345(width of deck in mm) and subtracts the y size of the carrier and then adds off_y.

return Coordinate(
    (rails - 1) * _RAILS_WIDTH - resource.off_x + 100,
    resource.off_y + 345 - resource.get_absolute_size_y(),
    0
)

If the carriers are specific to tecan do we need to get rid of off_y? It is only used in when setting up the deck. I suppose it could be integrated into the coordinates for the resources on the carrier.

[rickwierenga]

i pondered this a little bit in this forum post: https://discuss.pylabrobot.org/t/merging-tecancarrier-into-carrier/243

This is opposite to how I visualize it. How does Hamilton work?

how you visualize it :)

front is lowest y, back is highest

in PLR we standardized to this. That is why for EVO the y-coordinates are inverted right before sending firmware commands, because the firmware has a different coordinate system. But on the front end we always use the universal PLR coordinate system.

pylabrobot/pylabrobot/liquid_handling/backends/tecan/EVO_backend.py

Line 687 in 98ef632

y_positions[channel] = int((346.5 - location.y + op.offset.y) * 10) # TODO: verify

pylabrobot/pylabrobot/liquid_handling/backends/tecan/EVO_backend.py

Line 875 in 98ef632

y_position = int((347.1 - (offset.y + resource.get_absolute_size_y())) * 10 + parent.roma_y)

I suppose it could be integrated into the coordinates for the resources on the carrier.

Theoretically it would work, but here's the thing:

• we would still need to store this information somewhere
• it's extremely hacky, you would say the carrier is at a different location than it actually is. this is confusing

what i think is needed in this case is that we change the universal Carrier class to include these parameters. Because you can imagine every Carrier on any platform might have a behavior that requires this. For Hamilton-made carriers we would just set it to 0. (Even for Hamiltons it's a good feature though because we might imagine a user custom 3d printing their own carrier which requires an offset in x or y.)

[nedru004]

I used a tip to determine the x,y,z position of the "knobs" on the tecan deck. For rail 1, left is 101, front is 276 (machine value = inverted), bottom of deck with a 96mm tip (1000 ul) was 32.

For x_position the carrier is placed on the deck using this:

pylabrobot/pylabrobot/resources/tecan/tecan_decks.py

Line 138 in 98ef632

(rails - 1) * _RAILS_WIDTH - resource.off_x + 100,

Then 100 is subtracted when finding that location

pylabrobot/pylabrobot/liquid_handling/backends/tecan/EVO_backend.py

Line 686 in 98ef632

x_positions[channel] = int((location.x - 100 + op.offset.x) * 10)

That seems pointless to add and subtract 100. Plus, for me I am off by 130 and need to use large offsets. Perhaps this is an error?

[nedru004]

I used a tip to determine the x,y,z position of the "knobs" on the tecan deck. For rail 1, left is 101, front is 276 (machine value = inverted), bottom of deck with a 96mm tip (1000 ul) was 32.

For y_position the carrier is placed on the deck using this:

pylabrobot/pylabrobot/resources/tecan/tecan_decks.py

Line 139 in 98ef632

resource.off_y + 345 - resource.get_absolute_size_y(),

We talked about using the "knob" lfb as the reference point and using off_y to determine location. I plan on calculating coordinates of the carrier with the knob location 276. I then need a way to invert that so I will keep using 345.

345 - (276 + resource.off_y) 

Then calculating the Tecan coordinates to invert them with:

y_positions[channel] = int((345 - (location.y + op.offset.y)) * 10)  # TODO: verify

off_y could be measured or calculated from carrier.cfg. Not sure the carrier attributes nor the equation to use to calculate off_y to match this new coordinate system. I would prefer to recalculate off_y instead of measurement for each carrier since I only have a few carriers, however I think some of the carrier.cfg values are wrong.

Here are some measurements I took:
MP_4Pos_flat: measured off_y=53.4
values from carrier.cfg: off_y=51, size_y=380

DiTi_3Pos: measured off_y=16.3
values from carrier.cfg: off_y=24.7, size_y=374

[rickwierenga]

I would prefer to recalculate off_y instead of measurement for each carrier since I only have a few carriers, however I think some of the carrier.cfg values are wrong.

it is unfortunate to not use carrier.cfg, since we have the illusion of removing carriers that we previously supported

however, we did not actually have those resources previously. an incorrect definition is useless after all

i would actually argue it's better to remove/raise an error for incorrect resources (with the information about the attributes that are missing)

Here are some measurements I took:

These are a little bit confusing to me. The measured-carrier.cfg value is not constant. why?

how is it possible to currently use both the MP_4Pos_flat and DiTi_3Pos without significant offsets if the values are so incorrect? (You are able to use both right?)

one answer is that we don't understand tecan's definition of off_y correctly

one important thing is that after we fix the resource definitions (both ontology + actual carrier definitions), we should still be able to generate the same firmware commands (if the firmware commands are correct), or generate the correct firmware commands (which should only differ very slightly from the ones currently in the tests since the one in the tests have been verified to work on an actual machine).

[nedru004]

one answer is that we don't understand tecan's definition of off_y correctly

This is definitely true for me. There seems to be many attributes involved in the calculation not just off_y and resource position.

how is it possible to currently use both the MP_4Pos_flat and DiTi_3Pos without significant offsets if the values are so incorrect? (You are able to use both right?)

Here is an example of the values being wrong.
The DiTi_3Pos tip rack is not what I measured. I measured from the front of the carrier to the first position of the tip rack and I found it to be 13.4mm.

The carrier.cfg says it is 15.5mm

13;DiTi 3Pos;5/61;120/247/45;1490/3740;3;0;
998;0;1270/885;133/155/0;Pos1;
998;0;1270/885;133/1155/0;Pos2;
998;0;1270/885;133/2155/0;Pos3;

The tip_carriers.py says it is 70mm

https://github.com/nedru004/pylabrobot/blob/216ed9e27aa0c35344797dbeb8a4b2c3adeed957/pylabrobot/resources/tecan/tip_carriers.py#L143-L164

Here is an example of it being very close, but not what I measured.
MP_4Pos_flat. I measured it to be ~3.74mm

The carrier.cfg says it is 3mm
13;MP 4Pos flat;151/0;110/510/69;1490/3800;4;0;
998;0;1270/855;100/30/0;;
998;0;1270/855;100/990/0;;
998;0;1270/855;100/1950/0;;
998;0;1270/855;100/2910/0;;

The tip_carriers.py says it is 3.5mm

https://github.com/nedru004/pylabrobot/blob/216ed9e27aa0c35344797dbeb8a4b2c3adeed957/pylabrobot/resources/tecan/plate_carriers.py#L549-L577

It is strange that I can use an offset of -1.6mm for the y position and it will pick up a tip and aspirate from a 96 well plate. Not sure how to proceed. If we can figure out how the y position is calculated then we could calculate the real off_y using the rail "knob" as a reference. If we had more measurements, the pattern might be more easy to find or have AI find.