Cross Contamination Tracking in PLR

Hi all, I implemented a simple Cross Contamination tracking feature and was wondering what people in the community thought about having a feature like this fully fleshed out. I added it as an optional flag that users can turn on, similar to the set_tip_tracking() function.

If this flag is enabled, I maintain a set() on each Volume_Tracker object called liquid_history. This stores the names of all liquids that this tracker has aspirated in its lifetime. I define an instance of “Cross Contamination” when a Tip attempts to aspirate from a well that does not have an identical liquid history to that Tip. I implemented a CrossContaminationException that fires if this happens.

I also define an update function, where the liquid_history gets updated on dispense calls to be the union of its current history and the history of the destination well.

This approach is simple and works for my purposes, but I was wondering if the broader community had thoughts on how to improve this/get it distributed to more people. I have tried some test cases, and they’ve worked fine, but I am not familiar with how PLR formally does unit tests. I would love to collaborate with someone on this if anyone is interested. Thanks!

4 Likes

welcome to the forum!

I think this would be generally useful, please make a PR! I’d be happy to help with unit tests and anything else.

Is Tip currently powerful enough to track this as it is picked up and dropped in tip racks?

do we need/did you to extend Liquid to accept arbitrary liquids instead of the fixed enum it is now?

1 Like

great idea!

1 Like

As far as my understanding goes, yes! We never reset the state of tips as the protocol goes on, so the ‘liquid_history’ of the tip will remain for a whole run. I added a method that wipes liquid_history to simulate a wash step or treating it as a new tip.

I didn’t have to extend ‘Liquid’ because my code doesn’t use it. You can just set any arbitrary string as the name of a liquid. It may cause methods that use the liquid identity to affect how the robot handles the liquid to break though. I.E. changing aspiration speed for viscous liquids is pre-defined bc those liquids are in the enum. Regardless, CrossContamination is just tracking the identity of the liquid, so even for liquids present in the enum, their name should get stored.

1 Like

neat!