PLR Support for "Read Barcode" using the CORE Grippers?

General
1

Hello, does PLR support barcode scanning of plates (not tipracks) using the autoloader?

Basically something corresponding to the feature in Venus under ML_STAR>Single Steps>Transport>CORE Grip>Read Barcodes

1 Like
2

@CamilloMoschner added support for barcode reading in Exposing autoload carrier load, unload & barcode reading (v1) by BioCam · Pull Request #64 · PyLabRobot/pylabrobot · GitHub (and more recently started support for this in the resource model: Integrate Optional Barcode Information Into `Resource` by BioCam · Pull Request #522 · PyLabRobot/pylabrobot · GitHub)

but this is as a part of load_carrier using autoload

i don’t think we support barcode reading using the core grippers (do you just pick up a plate and move it in front of the autoload?)

i think it should be relatively easy to add support for this by dissecting the current load_carrier implementation (make read_barcode a sep method) and using the existing lh.move_picked_up_resource method to move a resource after pick up.

1 Like
3

Ok, I’ll try to implement it myself then.

do you just pick up a plate and move it in front of the autoload?

That’s literally what the Venus method does: it picks up a plate with the CORE grippers, moves the autoloader to the right lane, and moves the plate in front of the autoloader up and down until it catches the barcode scanner.

The same functionality can be done with the iSwap, and I thought that it was this in the PLR codebase:

3 Likes
4

and make a PR? :backhand_index_pointing_right: :backhand_index_pointing_left:

thank you for reminding me, it has been a while since i wrote this code :sweat_smile:

here’s the documentation for that command:

image
image1792Ă—980 86.9 KB

it seems to be a simple wrapper around moving the plate to the correct location. seems useful!

2 Likes
5

So you would suggest implementing the firmware command rather than building this using existing PLR methods?

2 Likes
6

Yes, I’ve left this TODO when I finally need it. Please make a PR and integrate it if you have some need and time :slight_smile:

A couple of notes that might help:

  • 1D Barcodes on plates are extremely finicky when you print and apply them yourself (I found it’s worth just paying the extra price for pre-barcoded plates, if available and if there’s budget for them)

  • the scanning height of the Hamilton 1D barcode scanner is 118mm above deck (i.e. 218mm absolute height), if I remember correctly

  • as a result you can only scan “MTP” plates (plates roughly size_z<20mm) on MTP carriers during autoload scanning - I’m quite certain by now that this is the main reason for the existence of the two carriers called MTP and DWP - only difference is their height to accommodate the fixed 1D barcode scanning height

  • when testing and integrating this firmware command, the gripper will move up and down in front of the barcode scanner: be mindful that therefore there must not be a carrier in the tracks to the left of the barcode scanner!
    (Or only ones with low z-height in the first position)
    Otherwise the gripper will crash the plate you want to read into the carrier :eyes:)
    (Yes, same applies for VENUS :joy:

7

Absolutely, there is no other PLR STAR method yet that accesses the 1D barcode reader.

But it’s super fast to implement with the firmware info Rick shared above and looking into the STAR_Backend.py to see how other methods are constructed.
It is also a great first PLR contribution showcase to convince managers of how quick we can modify PLR to what we need, in any company, at any time - worked amazingly for me :smiling_face:

2 Likes
8

just the one that you made as a part of load_carrier right?

but the one that integrates with an iswap (C0PB) is a command no one ever implemented.

[quote=“CamilloMoschner, post:7, topic:250”]

if you wanna use the iswap for this, yes i recommend implementing the firmware command C0PB that I shared the docs of. Should be extremely easy (minutes) to do.

For the core grippers there is actually this command:

image
image1792Ă—662 60.7 KB

which would actually be better than what i originally suggested (move and call the new read_barcode as two separate commands), because it probably has some hamilton-written logic in it. hamilton firmware software is excellent so we should use it when we can. this should also be very very easy

as camillo said, an excellent first pr. please let me know if i can help with it

3 Likes
9

I’ve been using the “Move Plate to position using CoRe gripper” command as reference (just above what @rickwierenga sent).

I noticed that sometimes the PLR default values don’t match the Hamilton default values. Any reason for doing so? For example, in the core_move_plate_to_position:

the default z_speed in PLR is 500, while in the manual it’s 1287. Is it different units? The minimum traverse height is then the exact same number, same as x acceleration index.

10

Sometimes the default values in the firmware commands are not practical. The most obvious example is for xp (x position).

I guess it is kind of arbitrary, but if a default value is not (often) desired we can just change it. The firmware doc is just a suggestion (which we use when we don’t know/need better). It’s better if the user can call the function with minimal parameters and the function does what they want.

(most cases where the default plr value differs from firmware is actually when venus itself sends different values for that parameter.)

1 Like
11

is it working? do you want to make a PR? :slight_smile: