I wanted to kick of a conversation on converting Hamilton Venus Methods into PLR code. I think this could increase adoption if we make this process smooth. I know there is a lot of us who built significant infrastructure pre-PLR in Venus.
I’d be interested in if anyone else is tackling this problem.
The problem: There is a lot of “hacky” things that you have to do in Venus that you don’t necessarily want to replicate into PLR. This complicates a 1:1 transfer
The hacky things off the top of my head:
- The use of only 1D arrays for everything
- Custom dialogs built in Windows with limited UI options
- Poor file I/O
- “Hand built deck .lay files” (we actually programmatically build our decks in the .med in Venus similar to PLR but I know this is not the standard)
- Error handling of pipetting steps is check boxes deep in the GUI
My current attempt to speed this up is an AI skill that recognizes Hamilton methods, launches a small python script that runs the Hamilton files through the Hamilton HxCfgFilConverter (FYI Hamilton is not encoded in standard UTF-8) , builds a markdown of the logic and some other useful comparisons. I then spend an hour or two in plan mode with my AI and deconvolute the above hacky issues, who then writes a PLR method. Not perfect but a start. I can ask my company if I can share this skill if people find it valuable!
I have a secondary skill that is familiar with Hamilton firmware that then does a comparison of the Hamilton COM and Trace, to the PLR version. Obviously there is a lot of things different but with AI you can get 85% of the way there. The firmware commands shouldn’t change that much if you’re pipetting in the same places, same volumes, and at the same internvals.
Anyone else tackling this? Would be great to share ideas! This method is obviously not deterministic, which could probably could be improved.