Creation of a ChannelHeadAdapter (?)

dev discussion
1

Hi everyone,

I was just starting an integration of the teaching needles on Hamilton STAR(let) machines, and found that @rickwierenga just finished one in PR#300. Thank you, Rick!

This made me wonder whether we should consider an extension:
A teaching needle can quickly be modelled as a 300ul_tip but I would like to find an alternative to this soon.

Problem Statement
The teaching needle is closed at its bottom → aspiration and dispensation is therefore not possible → forcing these actions would lead to the piston-motor working in compressed modes, and I am wary this could damage the piston-motor.

Proposed Solution
I propose the creation of something like a ChannelHeadAdapter, representing any object that can be picked up by a channel but that restricts that channel’s aspiration and dispensation commands from being executed.
In theory the set of ChannelHeadAdapters could include…

  • teaching needles,
  • CO-RE grippers, and
  • bespoke tools, e.g. rubber-patted adapters that can push objects on the deck (e.g. I have seen slide wash stations in which a slide is located on a hinge that can be pushed in between slanted/pitched and horizontal positions using such a tool [I couldn’t find a video]).

In the case of the CO-RE grippers it seems that they already block aspiration/dispensation but for teaching needles and bespoke tools we would need to create a new Resource or perhaps Tip subclass to manage this behaviour.

Please let me know what you think

1 Like
2

love this idea!

what would such a class look like exactly?

attributes could be:

  • height
  • fitting depth (in case of hamilton)

Tip could even be a subclass of this!

1 Like
3

Yes, I think you are right, this could be the bridge to make Tip a Resource subclass:

Resource → ChannelHeadAdapter → Tip

Based on Resource:

  • size_x, size_y, size_z
  • fitting_depth (even for non-Hamilton tips, even friction-fit tips have to have a max-channel into tip immersion depth?)
  • maybe a twod_pickup_location? i.e. the 2D coordinate to which the channel will move to and pick the tool up: thinking about an L-shaped spatula for microscope-slide pickup here :eyes:
    (why: too dangerous for the iSAWP, too small for the CO-RE gripper)
    by default that would just be .center()
    it seems to me like a universal attribute of tools that are to be picked up by a channel, but because it is a complex concept should probably be “defaulted away” until someone needs it for some specialised tool like this one.
  • aspiration_compatible: bool (if it can be used for aspiration in must be able to be used for dispensation?)
  • conductive: bool (would finally allow us to distinguish between conductive and non-conductive tips programmatically; but in this case at a higher level than just the tips!)

There might be some more attributes but the rest I believe is actually more focused on making type-dependent modifications to commands like aspiration and dispensation.

1 Like
4

agreed on all.

maybe just pickup_location (in 3d - which at that point shouldn’t have to be clarified in the attr name)

wicked

can be checked by seeing if it has a VolumeTracker

1 Like
5
  • fitting depth (in case of hamilton)

The fitting depth of all Hamilton Tips is the same! At least if you talk about the overlap between the pipett and the tip when the tip is coupled.

6

I think it’s different for pip, 96 head and the 5 ml channels.

7

Yes, 5ml Channel is different, but 1ml Channel and 96 Head should be the same (I did not check again), at least the same tips are used.

But the main point is: The change discussed in this thread talks about the fitting depth as a property of the tip when it’s actually only dependent on the channel.

1 Like