Our team has been looking for a solution to centralized method file storage, particularly for liquid handlers and other integrated devices. As we’ve scaled up, it’s become a real headache passing .zip and .pkg files around, with several different versions of each method on different machines. Consistency between the same method running on a different machine has been tough. So far, I’ve been able to get git repo’s set up for Hamilton Venus method files, but the execution has been a bit clunky: the binary files associated with methods create merge conflicts, making branching impossible. I also need to implement line omissions for the checksum verification at the end of each HSL script. This approach has worked OK, and allows for good version control and remote collaboration, but I haven’t found a good solution for other platforms (Tecan, Beckman, Agilent etc.)
Wondering if anyone has any other approach to this? Trying to also set this up for labware and liquid class files with mixed success as well. Any insight would be helpful!
@LordNorm Also, a git repo should work for your agilent protocols and dependencies (Labware and Liquid Class are stored in the windows registry so you can export them as files
Here is an example, though they actually used the VWorks Export for labware and liquids.
What is in your gitignore file? We only track the Methods/, Labware/, and Library/ folders in the main HAMILTON/ folder and I haven’t got binary merge issues.
I’m pretty sure you can also toggle off the checksum security features as well.
I’m not the original poster, but concerning methods, the .med is binary, so can’t be merged, and the hs* files have comments with venus line numbers on, so if you insert a line in the middle of the method, all the comments below it will change as the line numbers have changed. We’ve ‘solved’ this by stripping out the comments using a github action, but it’s not a great solution.
You can toggle off the checksum verification, but that only means Venus will ignore the checksum, the line is still generated in the HSL file. You’re right though, I actually don’t need the gitignore line for simple commits in the same branch. The issue comes in with what @Gareth said, binary files can’t be merged, so merging branches or merging 2 separate commits on the same file isn’t possible as far as I can tell.
Git seems like a useful solution for version control on Venus for like you said, methods, labware, libraries, but for branching I don’t think there’s a good solution within git.
Me neither but seems people have used it to overcome binary merge conflicts when using git. I haven’t seen real value gain with branches as we just maintain single timeline. I can ask around more to the software industry folks I know out west though on this topic
sounds good, if I figure anything out I’ll let you know as well.
The real gain for branching is just to have a separate dev branch for optimization while the robot still can run production workflows. Takes the mess out of having to double check to make sure the right version of the method is being run