Changing grip modes inside script

Is there a way to change grip mode (narrow, narrow-reverse, etc.) during execution? For example, if RGA normally grips a labware at narrow side, but I want it grip wide to, say, read a barcode or to avoid hitting another labware at an adjacent position, can can do that in the script?

I don’t think you can do that the easy way. I do however think you can make your own logic around it.
Like so:

1 Like

FluentControl looks at the Allowed Orientations that you can find at the Carrier Definition at Site Definitions for both carriers that are involved in a transfer;

For a direct move at Transfer Labware it will choose an orientation that is allowed on both carriers. For example, let’s assume:

  • 7mm Nest allows all orientations Narrow, Narrow Reverse, Wide, Wide Reverse
  • Barcode scanner carrier definition only allows Wide
  • Hotel only allows Narrow

→ RGA must drive in Wide from a 7mm Nest to the Barcode Scanner because that is the only orientation both carriers allow.

→ RGA is allowed to take all 4 orientations from one 7mm Nest to another 7mm Nest, which usually means it takes Narrow as first choice. (but note there could be Allowed Orientations from the base segment underneath the 7mm Nest which could limit the choice for a Nest standing on top that segment site)

→ RGA cannot directly move from Hotel to Barcode Scanner in the above scenario because there is no common Allowed Orientation for both carriers. In that case it will move via a intermediate position / regrip position and automatically swap the orientation during the transfer, if there is such a carrier on the worktable (typically the 7mm Regrip Nest / 61mm Regrip Nest from the Control bar but can be configured at Configure and RGA there is a dropdown that would allow to select a location for regrip)

→ If you cannot achieve the desired transfer, then you can also use a Execute Single Vector commands, as per the post from MortenSkovsted above. It typically needs two Execute Single Vectors command (first Vector from the source carrier to grip the plate, second vector from destination carrier to move there and release the plate) . With a Set Location Script Command you can update the labware position on the worktable if the vectors result in a move of the labware to a new position.


Thanks, @Snowball and @MortenSkovsted.

Most of our nests have more than one orientation allowed, but it seems to me like FC selects the best orientation to grip and not necessarily what I want if I need to read the barcode. What I’m thinking is to move labware to a certain location with the orientation I want (might have to through re-grip) so that I can read the barcode. One issue I have with this is that if I want to read a bunch of barcodes, there would be a lot of labware moves. Luckily, I don’t have the need for this right now (all labware are pre-scanned in the carousel before being processed).

I have always avoided using Execute Single Vector, because it does not check for bounding boxes (I hope I am wrong on this one) and there is always risk of collision (I crashed RGA “a few times”). Well, if there’s no other option…

My impression was that the preference of FluentControl is N, NR, W, WR (i.e. in the same order as the checkboxes), though I don’t know for sure. You could limit the Allowed Orientation at the Barcode Scanner Carrier to only Wide and then it must drive Wide to the Barcode Scanner even if the Source Carrier/Nest allows multiple orientations (including Wide). Or do you plan drive to the barcode scanner / target carrier in various orientations?

FC uses the PathFinder to drive from wherever the arm is positioned at the time until the Safe position of the vector when it starts the ‘Execute Single Vector’ command at a Safe Position. At least that’s the case with option ‘from safe position to end position’ + ‘and back to safe position’ which is what you most often do in order to drive in and out of a carrier (including optional grip/release an object at the end position).

Perhaps ‘Execute Single Vector’ with the option ‘from end position to safe position’ doesn’t use the PathFinder & Bounding Boxes because a vector’s End Position is normally expected to be inside a Bounding Box. Whereas a vector’s Safe Position is normally expected to be outside of a Bounding Box.