VWorks: Anyway to reuse a plate from a storage device?

[jnecr]

I’m almost positive that I’ve done this before, but just can’t get it working. I want to store reservoirs in a Minihub because the deck of the Bravo itself is already crowded and I have three reagents that need to be in reservoirs (PCR Bead cleanup). I have a protocol that works great for one plate, but when it comes time for the second plate for cleanup the reservoirs cannot be spawned again from the same Minihub location. There is no plate for pickup it says when VWorks deadlocks.

I’ve tried defining the reagent reservoirs as single instance labware, but then they won’t leave the deck of the Bravo because they are waiting to be used in the second instance of the plate to be cleaned. This causes a deadlock because there isn’t enough space on the Bravo for everything.

Is there anyway to execute a SQL update command to update the inventory database to reset the reservoirs? Am I doing something wrong with the design of my protocol? Right now it’s pretty long and complicated, so not worth screenshotting. But I may slim it down to something simple for testing and I’ll add a screenshot of that.

Thanks for any help!

Is @Pete still around? If there’s anybody that will know it’s Pete.

[Pete]

Hi John,

This is possible; my strategy for reusing plates is to use plate groups. (not location groups)

For the first instance of the process, you can unload from by location. Then, when the plate returns to storage, you load it into the plate group. On the second iteration of the process, you would unload by group. and this should give you the plate.

[jnecr]

So I think I figured it out. Or at least I have a working protocol that will reuse the plates from the Minihub.

Instead of adding a single run to the runset manager with the number of plates that I want to run

runset.appendProtocolFileToRunset(protocolpath, numberOfPlates,'',FormName);

I added one run of the protocol per plate that I want to run and with writing to files I manage where the source/destination plates come from in the Minihub:

for (i = 0; i < numberOfPlates, i++){
runset.appendProtocolFileToRunset(protocolpath, 1,'',FormName);
}

At the end of every protocol I just overwrite a file with the next iterated number, 1 > 2 > 3 and so on. Seems to work OK for now.

[Pete]

Now your orchestrating!

[mauro]

Yes that’s a good solution.

You could also simply set a variable called - say -

runNumber = task.runNotes || 1;

at the start of the protocol and do the following in the cleanup, at the end of the protocol:

runNumber++ ;
if (runNumber < numberOfPlates) runset.appendProtocolFileToRunset(protocolpath, 1,runNumber,FormName);

And you start the protocol only once. The first time task.runNotes is undefined and therefore runNumber is one. The protocol then launches itself passing runNumber + 1 (i.e. 2) and this time task.runNotes will be 2 and populate runNumber… and so on!

[mauro]

Another possibility is to use this trick:

1. first create a “location group” (in my case it is called “reservoirA”)

2. In the “unload” task of your protocol add this code (in the code below I am supposed to reuse my “reservoirA” location 4 times):

unloadArr = [];
if (plate.instance === 1) {
   for (i=0; i<4; i++) unloadArr.push("reservoirA");
   task.unloadFrom = unloadArr;
}

3. Check this box in the load task:

4. check this box in the protocol options:

5. Run your protocol (just a test protocol):

6. The Gantt chart shows that 4 plates were unloaded always from the same slot/cassette and placed back:

The bottom line is: you can use the same location on the Minihub multiple times if you populate task.unloadFrom with an array containing as many “location group” names as many unload/load instances you need to generate.

Finally, I would like to share a few lines from an old “PlateHub” manual which also apply to the MiniHub:

• task.unloadfrom for Unload task: it expects an array of strings of either location group or plate group.
  e.g. task.unloadfrom = [“Cassette1”, “PlateGroup1”]

• task.loadintoByLocation for Load task: it expects an array of strings of location group.
  e.g. task.loadintoByLocation = [“Cassette1”, “Cassette2”]

• task.loadintoByGroup for Load task: it expects an array of strings of plate group.
  e.g. task.loadintoByGroup = [“PlateGroup1”, “PlateGroup2”]

Note: task.unloadfrom, task.loadintoByLocation, and task.loadintoByGroup should only be called once for the first plate in the batch because these functions re-construct the plate groups internally, and reset the plate pointer to the first plate.
e,g. if (plate.instance === 1) task.unloadfrom = [“Cassette1”];

[jnecr]

Lots to digest here.

I will definitely give these things a try in the future. I think your ways are more robust than my method of writing to a file and retrieving the variable from that file.

[mauro]

Any method that works is ok to me. I just wanted to show a “forgotten” feature of the Minihub.