I have a problem with my Fluent script. I am trying to have dynamic headmode and tip pickup with the MCA96. In nutshell user selects where are the tips into variable varStartingTip and based on a vb script the variable varHeadX is created indicating number of columns of tips to pick up. This of course will work only with full columns.
The issue is, that when the method is run it gives error: “The labware to use could not be found due to an invalid well offset”.
Previously I was testing it with fixed number in First X field and that worked, problems started only after replacing it with variable. I have double checked that the variable varHeadX has correct values.
Does anyone know what could be the reason/solution to this? Thanks a lot!
With issues akin to this one it’s always great to know what the system is seeing, are you commenting the variable values into your AuditTrail? What do they return for your use cases?
If the hard coded integer values are working, you may be returning a value that’s off.
The other option is that your script is “validating” and throwing an error with whatever varHeadX and varStartingTip have as their default variable values but that would be weird because it would show up when it compiles the script in the script editor.
I assume the value from varHeadX is used in the formula shown here:
which theoretically should be working with value 2, since tips are starting at column 5…
As you say, its not compiling issue. Below is the part of the VB script that passes the value…
Dim numColsUsed As Integer = CInt(Math.Ceiling(uniqueCount / 8.0))
’ Pass the number of columns remaining to FluentControl (varHeadX)
Host.SetVariable(“varHeadX”, numColsUsed)
Tough to say without more context (the Fluent UI only shows snippets of First X and Column in Tipbox)
May be good to audit the values in the boxes of your Pick Up Tips Command by creating an additional variable that contains this business logic and then using comments to have those values displayed in the audit trail. If you use this logic a lot, I recommend making it into a subroutine.
The error makes me think that this is resolving into something where the Fluent is trying to access a tipbox group-adjacent to the tip box selected, e.g. TipBox[000] instead of TipBox[001].
You could try populating TipBox[000] thru TipBox[002] and target TipBox[001] to see if it is accessing other labware within the group. Also you could try simplifying the VBscript to just pass 2 without the math to isolate the variable handoff, telling you if this is something within FluentControl or not.
I would try to select all 96 tips (Head & Tipbox) in the graphic and apply the offsets by variables onto that graphical selection.
Because now there is an column offset already by the graphical selection and another offset by variable which may be added on top of that. And if the column offset becomes >12 or <0 FC tries to move to the next tipbox with index 002 or 000 as per evwolfson’s post above; which could fit the error message that the labware wasn’t found.
Thanks guys for all your input. I have tried to add new boxes with labels 000 and 002 to check whether it would try to pick up tips there, but no success.
Then I tried to go back to my original logic in the script which was as follows:
Dim numColsUsed As Integer = CInt(Math.Ceiling(uniqueCount / 8.0))
Dim numColsRemaining As Integer = 13 - numColsUsed
Host.SetVariable("varHeadX", numColsRemaining)
I haven’t used it because of the short formula showed in the header of the Pick up tips command (12-varHeadX+1) which is the same thing, so I didn’t want to double it. But for some reason it works now.
I am not exactly happy with the solution because I dont fully understand it, but as long as it works I guess I am happy.
Thanks again for your ideas!
PS: It really bothers me how blackboxy the FluentControl is, most of the time I am just trying to figure out what’s happenning in the background.
Note how my values, even the hardcoded values, are commented into the Audit Trail. The variables that you don’t see here are commented into the Audit Trail in the group above this group.
I also made this into a subroutine that I can use over and over again and since the inputs can be quite variable, I want to log as much in the Audit Trail to troubleshoot in the future.
With any new platform, it helps to figure out ways to improve observability especially as you layer in VB scripts/Python scripts and any other external tools like LIMS, ELN, etc…
Establishing these practices also helps eliminate the blackbox feeling we get with any piece of equipment tbh.
This is one reason why I love VWorks. Every step in your protocol you can add JavaScript to log whatever you’re doing. You don’t need to add an additional step to your protocol just for the purpose of logging. Due to this I’m much better at documentation and logging when I’m writing a VWorks protocol than any other software.
Thats actually where I come from…so far, my most extensive experience is with VWorks so changing to FluentControl and Venus is quite a step in a way you need to think about scripting methods.
Yeah even moving from Evoware to Fluent Control was a change in the way you need to think because of the powerful digital twin tools plus microscripting (which is a liquid handling cheat code imo).
