Greetings,
Has anyone received an error like this on their Tecan Fluent? I feel like I’ve encountered something similar after a change was made to the deck definition but it’s been quite awhile since I’ve used the instrument.
Greetings,
Has anyone received an error like this on their Tecan Fluent? I feel like I’ve encountered something similar after a change was made to the deck definition but it’s been quite awhile since I’ve used the instrument.
What does your deck look like?
@luisvillaautomata Thanks for the quick response.
I’m actually asking this on behalf of a lab that is at a remote location so I’m not sure what the deck looks like. I’ll ask for a screenshot.
Are you wondering if the bioshake is a location that is unreachable by the MCA?
it’s likely that the bioshake nest location doesn’t have a vector defined for the MCA96 gripper, or the coordinates need verifying
@Optimize Thanks. I need to hop on Fluent Control and review how that is done.
I obtained a copy of their script was trying to run it on my stand alone copy of Fluent. The script imports, seemingly without issue (conflicts removed), but throws an error when I try to open it. According to the log viewer it looks like it “failed to deserilalize statements while loading the script.”
@luisvillaautomata This is what their deck layout looks. I haven’t been able to see their script yet so I’m not sure what plate they’re attempting to move to the bioshake.
Wonder if you’re missing worktable elements.
If it’s not a missing RGA vector, I would look into the plate position. It may not like being in front of the waste chute or near taller labware.
A long time ago I ran into this error with a deep-well plate on top of a shaker. The gripper wouldn’t path the plate to the shaker unless I used a vector to first position the labware above the shaker, then planted the labware down once the bounding box had already been entered in a “safer” way.
Is it possible that there is some similar bounding box tomfoolery happening here? Might be worth pulling the deck for simulation and messing with some direct commands to simulate where crashes are expected vs where they actually occur.
Possibly. I don’t import/export methods often but this is the first time I’ve run into a method that wouldn’t open after the import. Usually I just have to deal with orphaned labware.
That’s a good suggestion. I feel like there’s a lot of tomfoolery that can happen on the deck. We once had a tip box that was in one location and would then “jump” to another location when the method was started. We never did find out what the root cause was.
In the past what I have seen fail is that there’s a missing dependency (a labware or the Fluent frame & wall for some reason).
I believe significant upgrades have been made in newer versions of FC to address the latter.
That’s how pathfinder operates, it’s brilliant when setup properly and allows you truly simulate workflows with unmatched precision (IMO) but you need to do the legwork to dial in the details.