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
Yes this is exactly the use case. We actually also implemented a git branch check into our Venus methods that will stop method execution if Dev is checked out unless the user enters a password that only our engineering team knows.
My question for others that have implemented Git to manage changes to methods is how you handle deck layouts across instruments that may have different hardware setups (ie waste in a non-standard location)
and - this git branch management falls down when we have to make instrument-specific teaching adjustments - these types of changes would ideally be able to be pushed directly to master without a Dev-Prod release but the only way I’ve heard of people successfully implementing this has been through big fat csv files with all the teachpoints saved which is not an elegant solution to this problem.
Hello All,
we implemented git and bash on all our hamilton. we tried everything in past to make branches and merge conflit work but it alwasys have problems. This is the way we came solve this problem. we are using tags. so u can use tag 1 for production while u can work on tag 2 or 3 in development. I am happy to share our files and taks. @Stefan there is a way to share files ?
@Gareth : sorry for delay. there is no way for me to install anythign here. IF you want. please send me an email on erkalpeshgupta@gmail.com and i can send files to u