Fixing labware file dependencies

Hello,

I’m sorting through some legacy Venus methods and I’m noticing that some of my layout files are referencing ML_STAR labware files from a nonstandard location (another previously imported method). What good options are there for reconfiguring layout to fix the file decencies for original Hamilton files?

I’m also seeing that those duplicate Hamilton files are showing up in the Layout editor, what good options are there for filtering those out?

Thanks!

1 Like

Hi @3uLdispense,

In order to clean up which Labware Definitions are being used on your Deck Layouts, you’ll need to manually change each Labware to the correct directory, see instructions below:

If you are in VENUS 4 or earlier:

  1. Copy the Labware ID from the Labware Properties window (accessed by right-clicking on the Labware on the Layout). I’d also suggest taking a screenshot the XYZ coordinates from the Adjust Location window to avoid re-teaching manually taught positions.
    image

    image

  2. Delete the Labware from the Deck Layout

  3. Browse to the new Labware Definition you want to use, add to the Deck Layout, then Paste the Labware ID back into Labware Properties. If the Labware was previously snapped-in to a carrier site, then make sure to snap the Labware into the carrier site again before changing any XYZ coordinates in the Adjust Location window.

If you are using VENUS 5:

  1. Instead of deleting and re-adding the correct Labware Definition, there is an option to directly change the Labware after selecting it on the Layout:

NOTE: in any version of VENUS, if replacing a carrier (template) Labware Definition, make sure to remove (click and drag off of the carrier) all associated racks from the carrier before deleting or changing it, otherwise the associated racks will be deleted.

In order to remove the additional Labware Definitions appearing in the Layout Editor selection window:

  1. Find the additional copies of Labware Definitions and delete them (for default definitions, these will typically be in any location outside the ‘HAMILTON\Labware’ folder)

  2. Open Method Editor, then open the Labware Editor from the icon
    image

  3. Go to File > Generate Labware Category Index, and wait for a pop-up which states ‘Index Created Successfully’
    image
    image

  4. Close Labware Editor. If a Deck Layout was open while performing the above steps, close and re-open it and the deleted Labware Definitions should no longer be in the selection window.

Let me know if there are any questions.

Thank you,
Dan

1 Like

Just curious, what file path is being referenced? If it’s a “Jeff” folder then I’ve got a story for you.

3 Likes

I’m curious now. Story time!

It’s not a crazy story, but my old company had a very strong relationship with Hamilton that may have had unforeseen consequences. We often sent methods back and forth, and directly to engineers to assist with applications development, I think this is where all the trouble started.

When trying to develop methods for customers, it’s common to try to isolate interaction between different development projects - we did this with subfolders within Hamilton’s Method folder. What we didn’t fully understand at the time was exporting/importing and how it would duplicate libraries and labware within these folders when sending over to customers.

One of our development folders, the “Jeff” folder and eventually the “Jeff2” folder, held a lot of our base methods that became framework for a lot of customer projects. We used it frequently, and it started creeping into customer development folders as a reference for commonly used libraries (sequence, tracing, etc…). It became so prolific, that it became a sort of “virus” in that we started seeing it pop up at customer sites that we had never actually been to. I had personally seen installs at customer sites that had literally never had contact with the company contain this folder.

So if you ever run into a Jeff, Jeff2, or Clemson2 folder… now you know why.

8 Likes

Hahahahahaha

Hahahaha that’s amazing!

But also I see those code review processes aren’t so thorough :eyes:

Such a good story. To be honest, I think this is why dependency management is an important feature request for Venus 7. Would be great to have a python-like virtualenv with dependency pinning.

1 Like

Thanks for the helpful responses, and the great story. Thankfully I’ve avoided the “Jeff” virus, but I’ve got a bunch of method variations that are contaminated with extraneous ML_STAR labware, copies of standard (and non-standard) libraries in weird places, and cursed references to other methods sub-methods.

If you’ve got a method you want to make a bunch of different modifications to, it might be a good option to make method and layout templates. Don’t just Save a copy! Take the time to make your methods in a sustainable way that doesn’t drag several years’ worth of strange file dependencies all over your Hamilton directory.

Also watch out for any weird dependencies your sub-method libraries might be hiding.

Thankfully it seems like Hamilton has noticed this issue and put in some tools in later versions of Venus.

1 Like

I want to add a cheater and much faster workaround:

  • Find the new labware path
  • Convert the layout file to ascii using the Hamilton bin tool
  • Open the file in any text editor.
  • Find and replace the old path with the new path.
  • Disable checksum validation
  • Open and save the layout file. If anything is invalid, it will throw errors upon open
  • Re-enable checksum verification,

Done!

2 Likes

Whoa you can convert layout files to ascii?

Definitely!

Use HxCfgFilConverter.exe in Hamilton/bin folder to convert. It works for any “binary” hamilton file. You also don’t have to convert back so don’t worry about forgetting. Hamilton software can read the file both ways.

2 Likes

Thats astoundingly useful

1 Like

Would it be possible to versioning also layouts files by converting to ascii? Interesting.

1 Like

Yes, certainly it’s possible with a plain text format