This library has been mentioned in a few threads, but I realized it hasn’t been shared! It has since been uploaded to the repository we set up under Hamilton Libraries.
Please see this link for the folder containing the latest version of ATML.
The purpose of the ATML is to support tip management (updating the tip counter, tip loading dialog, etc.) on our larger pipetting platforms. This is a consolidated and updated implementation of tip handling logic, merging functionalities previously found across multiple separate VENUS libraries. For example, it includes support for stacked tip racks.
The library was developed and is maintained by our internal software development team. It has been in use in the field for some time and has gone through several revisions based on feedback from the Hamilton Applications team and our customers. We are in the process of incorporating it into our VENUS software training courses.
The installer for the library installs the library along with a demo method that shows several use cases (demo method can be found under Hamilton\Methods\Library Demo Methods\Tip Management Library). The library has a help file that expands upon its features and lists its limitations. As it is intended to be comprehensive, it is more complex, so there is a bit of a learning curve. So, in some cases, it may be more straightforward to use the default Tip Counting library. See below for a quick comparison of existing libraries and supported features and a compatibility list:
Support for:
HSL Tip Counter
Visual NTR
STAR MPH96 Tools
STAR Tip Tools
ATML
FTR
Yes
Yes
Yes
Yes
Yes
NTR Management
Yes
Yes
SkyFrame Management
Yes
Tip Box Management
Yes
Optimized Tip Pickups
Yes
Yes
Tip Defrag
Yes
Yes
MPH Shifted Tip Pickup
Yes
Yes
Integrated Tracing
Yes
Yes
Yes
Yes
Compatiblity
Support for all tip rack types:
FTR (Framed Tip Rack)
NTR (Nested Tip Rack)
Tip Boxes
SkyFrames
Supported Instruments:
STAR
STAR V
VANTAGE
Pipetting Hardware:
1000µL Channels
5mL Channels
MPH96
VENUS:
VENUS 6 and up.
While it’s intended to be comprehensive, there are still pending features and likely use cases we have not encountered. We can provide any feedback directly to the development teams for consideration in future updates.
Thanks for sharing Eric. I have used this library for a couple of months now and it truly is a huge step forward compared to what we used to have. I have stumbled upon a situation I cannot seem to solve: If I am using two (or more) different tip types and want to use the 96 head (and reuse tips) it seems to not work as I hoped it would. Placing tips back in the rack and then picking it up later is not working if the system should also use another tip type in between. I understand that this is one of the extreme cases and I managed to solve it using a second tip rack adapter and place the tips that should be reused in this one. That seems to do the trick but then the ATML is not used. Overall I LOVE it. Keep up the fantastic work!
Thanks for the feedback! Yes, that would be a challenging use case for the ATML and one that has been relayed to the development team. I checked with a colleague who reported it - their recommendation would be to use the granular commands in the TipManagementLibraryComInterface to get the pickup sequence, reuse as needed, and then update when done. So, something like this:
Thanks Eric! I did come across an edge case and I am wondering if I am doing something wrong with the ATML.
I use the GetTipPickUpSequenceWithControlSequence but I believe that since it only had a few tips left in the layer, it overrode the channel pattern with “1000000” even if my control sequence had a lot more positions left.
The issue is that it proceeded with pipetting the subsequent steps before cleaning the NTR layer and picking up more tips, which led to a mismatch with my sequence/array handling downstream and a method abort. Note that re-running the simulation right after didn’t result in an error because it had enough tips in the layer to proceed accordingly.
Is there a way to program the method to mitigate that risk? Would turning off optimization mode work here or it would simply be a matter of a stronger coupling between the tip pickup and the sequence/array handling so I don’t get the mismatch?
You mentioned there are still pending features for this library. Is adding MPH384 pipetting capabilities in the works for the near future? Otherwise, is there anything preventing someone from adding MPH384 capabilities to the library sub-method?
@EricSindelar_Hamilton I’d like to report a small bug in the TipManagementLibraryComInterface.hsl library that is the backbone for the Advanced Tip Library Management smt.
For the function “GetMph96TipPickUpRowsSequence”, if there is an error, the trace file reads “Could not get pick up tip sequences for columns!” when it should read ““Could not get pick up tip sequences for rows!””. This is line 2380 when I open it in the HSL editor.
Also, I have a question on the Transport Helper submethod library (particularly the NtrTransport/NtrTransportPortrait submethods). If the transport of the NTR tip rack is NOT to waste, then the Get plate step will pull in relevant grip parameters(grip height, grip width, grip opening width, grip force) from the TransportDefinition.hsl library depending on if its a STAR or VANTAGE (even though the only parameter that differs is grip height).
If the NTR tip rack transfer is to waste, then its hardcoded to use Vantage specific grip parameters. Why is using the Vantage specific grip height ok in this situation for the STAR line? Thanks!
A new version of ATML has been uploaded to the repository here. The main new feature is a function called GetTipPickUpSequence for the MH96 head. This function is intended as a substitute for all other MPH functions, whether you wish to pick up rows/columns or complete racks. You can also use it to optimize your MPH methods and save customers’ tips by picking up incomplete rows or columns.
You may notice some redundant input parameters (i_intMphPatternMode vs. i_intMphPickUpSide). These were introduced in preparation for future modifications to the function to ensure compatibility.
New features
You can now create sequences for incomplete rows and columns to perform your tip pick-up with the MPH96 by using the GetTipPickUpSequence function. This function can also be used to create all other sequences (rows, columns and full racks).
Bug fixes
The IPG parking command bug has been fixed
Fixed an issue with an error derived from a missing container path/file on the deck.
SkyFrames: Fixed a bug where an empty sequence was delivered in a multilayer edge case.
Fixed a bug where an undefined labware property error was thrown during tip transport of 96 tips directly from the rack.
Tip counters in the Tip Edit dialog are now in a deterministic order.
Adjustment in the ATML demo method error handling.
Known issues
UCM2: ATML is not compatible with UCM2 middleware ≤ V1.01. However, if ATML is installed before the UCM2 middleware installation (V1.0.1 or higher), both are compatible.
Tip counters covering partial racks: If you use a tip counter on part of a rack instead of the full rack, an error will appear during defragmentation.
GetTipPickUpSequence: If fewer tips than complete rows/columns are requested in the last unit on the tip support, the return code NotEnoughTipsOnSupportPosition can be thrown.
I second Wictor’s point above about how to ensure a smooth update for the ATML. I was initially on ATML 3.0.2, but I had to import a method that was built with the 3.1.0 version and contained the new GetTipPickUpSequence function. I naturally had syntax error since that was an undeclared identifier.
I uninstalled the ATML 3.0.2 through the control panel then installed 3.1.0 with the installer above. When opening the method, it first flagged that the a specific file needed to be repaired (“C:\Program Files (x86)\Hamilton\Library\Tip Management Library\TipManagementLibrary.hs_”) but it was exactly in the expected path. And now it is throwing a different syntax error about TIPMANAGEMENTLIBRARYCONTROLLER::StartLogging & TIPMANAGEMENTLIBRARYCONTROLLER::StopLogging being undeclared identifiers
EDIT: It seems the issue was that I was missing the TipManagementLibraryController Library. Unsure if it is supposed to normally be added during the install of the ATML but I was able to resolve my syntax errors by copying over the relevant files from the library (smt, stp, hsi, hs_) from a different system we have.
Sorry for the delay, as I’ve been traveling. See below for some general guidance on installing and setting up new versions of the ATML:
Run the latest ATML installer. Unless otherwise specified, there is no need to uninstall the existing library.
Open the methods and submethod libraries that have ATML commands. If there are any syntax errors, the affected commands will be highlighted. Open each affected command and resolve the conflict(s). Save the changes.
Run the methods in simulator and perform water runs to fully vet the update prior to conducting any reagent or sample testing.
Syntax errors occur when functions get additional or modified parameters. The errors that are generated when you open a method/smt library post-upgrade essentially highlight the conflicts so you can then identify and resolve them.
Please let me know if that provides enough clarification or if more specifics are needed! We’ll try and highlight these changes better in future updates!
@EricSindelar_Hamilton is there any way to use the ATML for non tip sequences (e.g. selection of a sequence at runtime for wells in 24-well plates to feed).
I’ve used the HSLTipCountingLib for this successfully in the past, but I am running into an issue with visibility of the proper labware when multiple types exist virtually on top of the same deck position (e.g. 96-wp, 96-DWP, 24-DWP etc. each on their own deck layer). The overlapping labware types exist because the method gives flexibility for the user to select which type they would like to work with.
I find I’m still physically able to select the correct sequence (e.g. if the user selected 24-well plates, the sequence associated with that labware is the only one the Edit2 step of HSLTipCountLib will affect), however without the visibility, it is difficult to click on and select specific wells that you can’t see (click-and-drag selection for entire plates still works fine since the precision isn’t necessarily needed when someone would click/drag). All layers are visible in the deck layout. Is there a difference between setting “Visible by default” to Yes vs. No?
I was thinking “No” would hide everything except the active sequence (like when pipetting), but that doesn’t seem to be the case here.
This led me to the ATML and I was hoping it may be able to address this issue?
The ATML is for tip labware only, not for plate labware.
The “Visible by default” refers to labware, not layers. So, if “No” is enabled, then the labware will only appear visible when it is loaded or accessed during runtime. Many users prefer to set this to “Yes” so that all labware appears in the run control viewer from the get go.
I see the issue you’re referring to with the Edit2 step. There isn’t an option to select and view a specific layer, unfortunately. It will show all the labware which makes for a cluttered view, but as you indicated, it will only allow you to select the positions for the sequence for the labware you specified in the step.
