From Simulation To Real Run

Hello all! :slight_smile:

Feel free to move this topic where it belongs in case it already exists somewhere.

Simple question: Is it safe to try a real run, given the fact that the method works in simulation mode? Hamilton STAR, method created with VENUS

I have just finished my first method of simple pipetting, mapping files, barcode scanning and so on.
Now I want to see if it works on the robot.
Since there are so many parameters one can easily loose their mind and on top of that I of course don’t want to damage our robots.

However, the method works fine in simulation mode and I have gone through it multiple times in order to assume all possible errors and wrong thinking from my side.
Now I’m wondering if I can start a real run (with water first) just to see that it does what I want it to do, and at the same time does not catch fire or something, lol.

Thanks a lot!:slight_smile:

  1. be aware of teaching/labware configurations that may be fine in simulator but may not work well in real runs
  2. pay attention to labware movements (if moving plates around) it’s fairly easy to assign a sequence for pipetting when there’s no plate (physically) present

I’m sure the community will have additional input, but I applaud you doing a water run prior to running with reagents. I typically do a dry run before the water run for methods dealing with plate movement just to ensure the deck and sequences are assigned as intended.

I would also recommend possibly running the method in a stepwise iteration the first time, again physically making sure you’re confident in what the instrument is about to do.

3 Likes

If you’ve done all that and also confirmed your labware definitions, then I think you’re ready for a water run! For default labware such as tip and plate carriers, just make sure you’re using the right ones and for any other labware such as tubes and plates, make sure they are taught and defined properly which you can verify outside of running the actual method.

Check out the guideline for VENUS programming practices that provides a general overview of things to consider before, during, and after programming.

Best of luck!

-Eric

1 Like

All great advice so far.

One point I would also add is splitting up the run into individual steps or unit operations, and testing those individually. This can help you isolate any problematic steps and then troubleshoot those in isolation.

2 Likes

Thank you all for the quick response and good advices!
I will get a good weekend rest, come back on Monday with a fresh mind and go over the whole thing again, ask for input/opinions from colleagues and then actually try a run.
So excited! :blush:

1 Like

I’ll also add to everyone else and say, don’t be afraid to mess up somewhere. It’s pretty much a rite of passage to launch a plate into your ceiling. Have fun while doing, but learn what not to do next time. Screw up as much as you can before you do a live run with real reagents. Also when you break stuff you learn really quickly how to unbreak things and also get a good understanding of how your liquid handler or instrument works. Just be ready to have your local vendors number on hand for when stuff inevitably breaks.

2 Likes

It’s pretty much a rite of passage to launch a plate into your ceiling.

I’ve been using liquid handlers for 20 years and Bravos specifically for 10+. Just bent a barrel on our month old Bravo last week by being stupid.

Don’t be afraid to break things, it’s the best way to learn.

3 Likes

What I usually do:

  • Wrap individual steps in local sub-methods, so you don’t have to look at the complete run again whenever sth. goes wrong that you have to fix before continuing.
  • Check out those individual steps, if they are fine they are most likely fun when run altogether
  • Do this checking, especially for external devices: They are not really well represented in simulation, that’s where I catch most errors
  • Get a cordless keyboard and sit in front of the machine with your finger on the F6 button: You can pause VENUS execution after completion of a step at runtime. If sth. really bad happens I stop the robot to first have time to think. Espacially during the first few runs this can be really exciting and at least I tend to panic / overreact, so it’s great to get some time
  • As other said: Don’t be afraid to mess up sometimes. I don’t know how many times I bricked our Beckman robot, that way you learn to recover even from bad situations. Be prepared that you know the machine in the end, but your workmates probably never will to that degree. They will make errors that you will have to recover from time to time.

Beste GrĂĽĂźe aus dem Ruhrgebiet :wink:
Dominik

3 Likes

I don’t think anyone has mentioned this one:

Grab a second pair of eyes to validate the dry or water runs. When you script, it’s easy to get lost in the “why” and miss the “what” that actually happens. A friend can really help boost the usefulness of test runs prior to reagents.

3 Likes