Databases/Repo's for Method Files

LIMS & Systems Integrations
#1

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!

3 Likes
#2

Check out Puppet: https://puppet.com/

I haven’t tried it personally, but I have heard of people using it for what you have described

1 Like
#3

Will definitely look into it, thanks Pete!

#4

Puppet looks interesting but also what sort of Tecan’s are you working with?

And are you concerned about discrepancies/variations in the deck referencing?

#5

@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.

1 Like
#6

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.

#7

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.

#8

I did a SLAS poster about this a couple years ago. Here’s a link
Since then, I’ve been able to do the same thing using git.

2 Likes
#9

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.

#10

Could you use the HxCfgFilConverter on HAMILTON\ after a pull and before a push?

#11

What about git checkout --ours *.[med|hsl|stp|lay|res|sub] or git checkout --theirs *.[med|hsl|stp|lay|res|sub]

#12

Never used it before, what would you propose doing with it?

#13

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

2 Likes
#14

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

#15

Interesting. Have you got any examples of how they are using this to do the binary merge conflicts?

1 Like