Hey y’all. Fairly new to the Tecan Fluent, but I have had the Intermediate Training they offer. My setup has Bioshakes from 3rd party integrations. I have an assay that involves, moving plates to and from 1 of the shakers, while the other one shakes continuously. I’m having trouble, trying to figure out how to accomplish this without having to use labware names in a subroutine. I know I can have the RGA move the plates, but the subroutine commands relies too much on the labels of the plates, and I need to do this about 4 times and I would rather it be based on how long that plate needs to shake and where that plate needs to move, vs the name of the plates having to match in the main script and the subroutine. I hope this makes sense. Thanks in advance.
What is in your subroutine? Is it just executing Bioshake commands to start/stop shaking or is it also setup with RGA movements to move the plate on/off the shaker? If your plates are numbered consecutively [001], [002], [003], [004], etc. you could use the index and a loop to increment the plate. Can you post an export of your existing script? Mike Mueller Nucleus Automation Partners LLC
Yes, the subroutine, is just executing Bioshake commands to start and stop shaking after a certain time. I haven’t added the RGA movements to the subroutine because I gave the plates unique names because of their contents. However, if it will give me a better workflow to just number the plates and increment the index then I’ll do that, I haven’t thought about it that way. I guess the biggest thing I’m worried about with that is making sure the timing matches up on the main script and subroutine because I have aliquots at different time points to different plates. Then each crash plate needs to shake for 5 minutes and placed back to its cooled carrier. I attached an image of what I have in the subroutine so far.
If you want dynamic labware with dynamic bioshake from one subroutine format, you need to create device group drivers. This way you can use 1 subroutines over and over and the shaker and plate become variabilized options.
With that said the default naming scheme “PLATE[001]” unlocks a lot of nice features, especially when they’re in sequential nests.
Also you can variabilize the subroutines so you can "Subroutine " + index where index is the loop variable.
This makes sense. I will give these suggestions a try and let y’all know what I come up with. Thank you !
If you’re worried about timing matching between main script and subroutine, there’s a way to pause the main script until a selected subroutine finishes. There’s a radio button on the “Subroutine” command that says something like “wait for subroutine to finish,” and makes the command show up as “Join Subroutine” in the main script. It’s confusing because it looks like you’re running the subroutine a second time, but it’s really just a command to wait.
If you want to keep your descriptive plate names and still use the RGA within the subroutine, you can pass the names to the subroutine as variables. Make a variable within your subroutine called “PlateName” or something, and tell the RGA to move PlateName to the shaker you want. In the “Subroutine” command, there’s an option at the bottom to pass variables into the subroutine from the main script that you can expand by clicking the triangle next to it. You can use that to link the name of the plate you want to the variable PlateName. You could even pass the name of the shaker you want to use as a variable to make the subroutine even more flexible.
One other thing you can look at is setting the scope of your variable to “Run” instead of “Script” in both the main script and the subscript. That will make the variable global and available in both scripts (when you have the variable using the same name in both the main script and the subroutine).
One other thing I would consider is approaching the subroutines a bit differently. You might want to separate out the ElmLock and Shake On for the Bioshake as one subbroutine, and make the ShakeOff / ElmUnlock a separate subroutine. This would give you greater control over the timing, and in particular as your example shows Start Timer / Wait for Timer, if you handle the timers in the main script, you could then put other commands in between the Start Timer and Wait for Timer so that you have some other things running in parallel. As you have it here with Start Timer and Wait for Timer back to back without any commands in the middle, that is essentially equivalent to the single line “Wait” command.
Mike Mueller
Nucleus Automation Partners LLC