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?
