Improved or Better Smart Commands - for example, a Sample Transfer with the ability to mix… Also for how many iterations of FC have we had warnings in the manual about future deprecation of certain smart commands?
Dark Mode (pleaseeeee)
Developer Friendly UI
Fix UI elements that do not scale well for the small Touch Tools screens
Modules vs Subroutines… right now the delineation seems to be that one requires one less programmatic step.
Parameters variables - wouldn’t it be cool to add notes so engineers can understand the parameter requirements… maybe this is something that can differentiate modules from scripts in subroutines a bit better…
When it comes to “2. Jump To Line” I have some bad experiences with this from an EVO script I did not write myself but had to modify.
I think it can be a bit difficult to have comments that are actually part of your code logic, as is the case for “Jump To Line”.
Perhaps you can use “Leave Loop/Group” for your particular need? I know it’s not as flexible as a “Go To”/“Jump To Line”, but sometimes it can be easier to read (and understand).
(Maybe similar to your 5 in post 1)
What I would like is a better use of modules/Subroutines, and it would be nice to be able to pass an array to modules/subroutines. This would make it possible to make more modular scripts without having to make VB, which I do not have a lot of experience with.
Yeah first of all like with anything, if you don’t know what you’re doing it can be a disaster. However I’ve written complex scripts that utilize the “Jump to” logic that have never had issues and they are simple enough to adjust later for a junior engineer. Second, this ability is not uncommon in other softwares that are commonly found in labs with other liquid handlers so it’s not a request leap. Third, you can ALREADY jump around somewhat within a script with On Error Go To so the logic exists in some form in the software. Fourth, the point of the request is to literally not half ass an If/Else Group logic because scripts with lots of If/Else statements have compile issues. There’s something about If/Else complexity that can hang up the software even if it meets all programmatic requirements. I believe changes may have been made in 3.3 based on some of my feedback but I haven’t had a chance to use it yet.
To your request, you can in a way pass an array to a subroutine but you have to declare that array to be a “Run” variable. It’s not directly passing the information the way you would a “Parameter” or a “Script” variable but as long as your method is running, it keeps track of that data in the array when it was declared so you can access that data from within a subroutine or module.
I currently use the last bit for complex plate layouts and it works like a charm.
Which database links do you need? Also are you using the audit trail ability?
I avoid smart commands generally but I was under the impression that you could make it so the temp scripts are visible post-run and only auto-deleted after X amount of days? If not, yeah an audit ability for something like that would be nice!
This is why I would love C# support, something with better documentation so you’re not trying to dig up 15-+ year old books or examples.
I’ve never used Instant Pipetting but it caused database issues so we would avoid it like the plague. In fact, I would go back and uninstall it from EVO systems.
Let’s create a new thread for this topic so others can Google it in the future and be led here but also share their own experience, let me write something for the forum.
I might be a bit late to this thread, and less in depth on the coding side but my QoL wishlist on the “standard application use” side of things would be:
Better documentation of Tecan variables within microscript. e.g., IndexTip, detectedVolume, etc and how they interact.
Passing variables b/w main- and micro-script without exporting to txt or similar. This alongside subroutines inside microscript would make it much simpler to add traces/tracking to the LC
I can’t tell you how many times I’ll begin scripting and the dang arms don’t properly initialize, Move Tool shows no arms configured, and I need to restart the software. On that same subject, having to start the software after a crash and being greeted with a message to restart once again is never fun.
It would be great if the normalization, dilution, and other super-smart commands worked.
Logviewer is atrocious. I know why it can’t show firmware commands like with EVO but damn it would be great if it was just a little better and a bit more informative on errors. Things like “height out of range” give you a good indication but don’t pinpoint the interaction that caused the issue.
Let me expand the variables section or drag/pin like other UI elements. its SO CLOSE to a great feature, but not if I can only see 5 lines at a time.
Validation needs to show more info on errors within loop, and I think would benefit from being redesigned a little bit. Maybe something like grouping errors… that way changing the name of a single POS or plate doesn’t lead to 50 identical errors.
Echoing @luisvillaautomata request for mix parameters in smart commands. I hate adding pre- or post- mixing to microscript to match what could’ve been done in 5 seconds on an EVO.
i’m tempted to run a “FluentControl Bootcamp”,
like a “show & tell” for “best practices” using the software
we all have the same challenges
FluentControl is a great programming language - not without it’s nuances/issues,
but some parts are better than EVOware, other parts not so good
i found the training approach isn’t fully aligned with how best to utilize the software in the way it was conceived,
any interested parties ??
not sure of admission’s fee,
It would be great if there were more offerings for training outside of the Tecan FC classes which are primarily oriented towards general usage rather than application scripting. That being said, I think the main barrier for people going from introductory to expert is lack of resources. Without Te-Wiki and a support group, it’s impossible to take a deep dive into the software, bugs and all.
Rather than paid courses, maybe we could start our own Tips & Tricks to highlight solutions and learn new programming - or maybe even learn that we’ve been doing something wrong.
You mean you end up with a blank Move Tool or it states that there are no arms? And yeah to restart the software I think it’s just a safety feature but it’s not really needed for every event. I think it’s just easier to tell operators to perform a hard restart every time JUST IN CASE.
Great example of less can be more although I’ve used the logs to pull firmware commands and other actions.
This is my biggest gripe (along with a lack of dark mode) but in a way it forces me to keep my variable construction to a minimum. Hence my love for arrays.
There are ways to make changes and have them autoupdate in the scripts but it’s not as obvious up front.
I got my hands on some info regarding this. Maybe you can use it.
Tecan recommends that you use custom attributes on the labware to transfer information to and from microscripts:
I can’t tell you how many times I’ll begin scripting and the dang arms don’t properly initialize, Move Tool shows no arms configured, and I need to restart the software. On that same subject, having to start the software after a crash and being greeted with a message to restart once again is never fun.
If this is the same bug we have seen (blank white box inside Move Tool), you don’t need to fully restart FluentControl. It’s possible to reset the Move Tool by switching to simulation mode, opening the Move Tool, and switching back to real mode. Should save a few minutes over restarting the software completely.
Without Te-Wiki and a support group, it’s impossible to take a deep dive into the software, bugs and all.
I’m not familiar with Te-Wiki. Is it a community solution, like this forum, or something created by Tecan? If it’s a website, could you share the link?
Sometimes you do have arm communication errors and they can be symptomatic of other problems.
The Move Tool problem you’re referencing commonly occurs for a variety of reasons but I believe mainly due to people not performing the shut down sequence properly after a crash or something akin to it.
