Has anyone been able to work with Tecan fluent methods and have git working? The official response I got was "scripts themselves live in the database folder in a non-readable format this file cannot be copy and pasted into a database folder "
After using git so long it is hard going back to versioning. What do other people do?
I’ve used FLuent Control with git but the real question is what are you trying to accomplish?
Track individual instruments changes?
Push an exact version of files to all Fluents?
General diff tool?
Semi-real version control of methods.
On our Hamilton’s we have a main branch and a dev branch. Then rebase main when pushing dev. This allows us to have a semi useful git work flow for methods. Diffs are pretty useless but at least we can easily roll back versions if there’s an issue in main. Along with that we can track changes over time easier. We also pull main nightly to insure no one troubleshooting touches the production code, i.e. you disable some steps and it gets reset at midnight.
You can do semi-real version control with scripts and method files since those don’t change that often (in theory). One caveat is that you need to make sure your GUID’s or UUID’s are the same across your systems which means that you’ve established a single source of truth and you import/export from that.
The only dev caveat is that Fluent Control doesn’t auto-register based on contents in a folder. It’s what’s in the SVN so you’ll still have to import or generate something with that file name in FC to register it with SVN but once it’s registered you can enjoy all of the other creature comforts of git. Liquid Classes probably don’t change too much so you can track them as well.
For things like labware and other components, eesh. Yeah that gets trickier and may be instrument specific because of the teaching differences and a lot of those files are handshakes.
Not sure about how it’s done with Hamilton but make sure to powercycle Fluent Control between updates since it compiles most things at load time.
With that said… disabling steps on a production script is bad practice. 
Edit: Hopefully this helps and I would appreciate any info from additional tests you run. An additional consideration is to think long term about the things that are not in your OEM software, your architecture and infrastructure, for potential workarounds.
Not sure if I’m following the workflow here. I was hoping to not have to use the import/export tool at all haha. Just access the script files in a folder and throw a git repo in that folder. That’s essentially what we do with Hamilton methods
I don’t script in Fluent Control anyway so this is all theoretical.
As of Sept 2025, FC has an SVN Repository and the SVN working copy. If you don’t want to import/export, you’ll need to manage the SVN Repository (copy) with the SVN working copy (this can be in git). My assumption is that you build your scripts within Fluent Control so you have to make that initial script commit into the SVN Repository (aka functionally similar to an import/export). Ergo you’ll need an SVN Repo that is your source of truth.
In your Database folder, you’re see a folder titled .svn. This is what establishes a link to your SVN repo. The SVN Repo has a unique UUID so you need to ensure that this is references in that .svn folder and is subsequently the same scross your computers. Once you’ve set up the aforementioned, you can git the SVN working copy which is what you see in the Database folder (add .svn to .gitignore.)
If you’ve made it this far, you’ll need to be selective about which items you track since system specific components will increment version when you re-teach and each system tends to have slightly different z heights in my experience (although they’re pretty close). In addition, if you have system specific LC info, say you’re constantly adjusting them per instrument, you’ll need separate setups for each system.
Hence you can git your SVN working copy but you need an SVN repo that is a source of truth.
Once again this is true as of Sept 2025, this may or may not change in the future. 
Do you script for fluent in another language, or just avoid fluent instruments in general? If you are programming fluent instruments outside of fluent control I would be keen to understand how! Fluent is inherently buggy it seems… I do see how its possible to write the .xscr (scripts) as .xml now, is that what you do?
Hmm we have to run a pretty old version of fluent for some compatibility issues with robocolumns, build 3.4.10.62215 so maybe we don’t have the whole SVN repository and SVN working copy?
I do see the .svn:
C:\ProgramData\Tecan\VisionX\DataBase.svn
but no “SVN folder”:
It looks like the actual scripts/method live in:
C:\ProgramData\Tecan\VisionX\DataBase\UserSpecific
Is it as easy for us just to gitnore the .svn and just track the UserSpecific folder?
The SVN folder is C:\ProgramData\Tecan\SVNRoot\SystemSW_1.0
Is it as easy for us just to gitnore the .svn and just track the UserSpecific folder?
Dude you’ve already figured it out, awesome. If you want to make this be your source of truth for all of your systems, just make sure that the UUID’s in the XML are the same and that the file name is the same.
Ok word.
So I think I’ll make two repos for simplicity:
I think this will allow us to all have the same UUID and be able to push/pull at will to the UserSpecific (script and method) folder and not have to mess with UUID replacement in the scripts. Lemme know if that sounds about right
I have not set up a process for managing the binaries in C:\ProgramData\Tecan\SVNRoot\SystemSW_1.0. Maybe you’ve done this for Hamilton but you’d have to try it withthis software to see if it works.
And you would probably have to capture everything in that folder, not just the db.
With that said, you can start with UserSpecific and work your way out from there.
Sounds good, this gives a way better lead than Tecan did! Thanks!
NP always happy to help and hopefully you can pay it forward one day, cheers!
Edit: BTW Hamilton & Git posters and presentations for SLAS exist galore, maybe we can do the same for Fluent Control lol.
I’m honestly praying that pylabrobot gets fluent integration, I feel how slow in these visual GUI’s now…
Could be down!! I’ll post back what I end up doing
FYI for future readers, Fluent is out of scope currently for PyLabRobot, so I am back to trying to get Git to work 
Hi @cwehrhan. We are working on supporting PyLabRobot like syntax for Fluent. Tentative naming PyFluent as we’ll generate FluentScript commands and use FluentControl to execute Firmware Commands.
So tracking in git just methods and scripts on the same computer is trivial. All you need to do is set up a repo in C:\ProgramData\Tecan\VisionX\DataBase\UserSpecific
Local version control on the same computer/instrument actually works perfectly; I successfully initialized Git in the DataBase\UserSpecific folder, committed changes to scripts and methods, and used git checkout to roll back versions without triggering any SVN errors in Fluent Control.
However, cross-system portability is not working. When I tried dropping in another user’s SVNRoot\SystemSW_1.0 and UserSpecific folders to mimic pulling from a remote repo, Fluent is unresponsive and won’t startup.
This is an issue as I do not want to track the entire C:\ProgramData\Tecan\VisionX\DataBase folder, as it holds instrument configurations.
Not having cross system compatibility really sucks, meaning we’ll have to update methods or scripts on a per computer per script basis. Unlinking method/script code from a instruments physical deck should be a no-brainer environment setup. I want to write my code once and deploy to multiple instruments all at once.
Yes the challenge here is that you need to work from basically the same SVN.
Not necessarily a problem when you have servers but it demands a level of purity that most companies do not have.
The GUIDs need to be the same and they can be made the same by importing from the same .zeia file.
There’s a path forward but you need to basically have a single source of truth.
Even if our robots are drastically differently configured? Tecan 480 vs Tecan 1080 with very different components, reader, cooler, etc. Same number of arms though and FCA
Same scripts?
