Similar to my thread in scheduling going to post a series of toy challenge problems. The point of these challenge problem is pure and simple. Toy problems that we as automation engineers can speak about freely in an open forum. I mean some of the constraints I’m coming up with are ridiculous and we will never be scene on the job, but that’s not the point. The point is to have fun and solve your way out of tricky problems. (With all the free time you have as an automation engineer 
)
Setup
Your company Awesome Therapeutics has two liquid handlers Iggy and Ziggy. They are configured like so.
Liquid Handlers
Both liquid handlers have the exact same deck layout it is only the hardware above that changes.
Iggy = {8-Channel Arm, Robot Arm Plate Gripper, Barcode Scanner, 20 Deck Positions}
Ziggy = {96-Channel Arm, Robot Arm Plate Gripper, Barcode Scanner, 20 Deck Positions}
The deck positions won’t really matter for this problem, but if you have a deck with more you can assume those deck spot are perpetually taken up by some device or need to be kept free for robot arm access.
Labware
Awesome Therapeutics is so awesome because they manage to do all their science using just two plate types. Every plate and tip box is and can assumed to be barcoded identifying itself and type.
Plates = {360uL Microtiter Plate V-Bottom, 300mL SBS Reservoir}
Tips = {~50uL Tips, ~300uL, ~1000uL}
- Since vendors all sell different sizes of tips match the tips size closest to these three bins of tip type. The point is that there are three different types of tips. (Small, Medium, Large)
Workflows
Your lab only has two scientists Alice and Bob and they only do the following tasks.
Task 1 : From an arbitrary single column on 1-3 source plates aliquot 8uL to all the wells of a single destination plate. If there was only one source plate and one destination plate then this would replicate an arbitrary column of the source place 12 times across the destination plate. When there are multiple source columns Alice always mixes at the end.
Task 2 : Aspirate a volume from (8uL - 300uL) from a large basin and dispense it into all wells of 1-5 destination plates. All destination plates will have the same added volume at the end. Sometimes the destination plates have sample in them and sometimes the plates are empty. When they have sample Bob sometimes wants to mix.
Problem
Write one program that can perform the tasks for Alice and Bob and be run on both devices. (This may not be possible on one type of device due to the heavily restrictive programming environment, however you could write your own installer to get around this issue…)
You are only allowed one UI screen with at most 3 inputs - if you can use less 
cheers to you!
- UI Inputs = {file_path :: String, continue_button :: bool, abort_button ::bool}
You are also allowed one or more confirmation screens for deck loading.
Awesome Therapeutics has an awesome software team as well so for any worklists for this solution you can assume the users will always download valid files to execute (no error checking on fields to make things simpler), however if the two tasks are solved with two different types of work-lists the program must be able to ingest both types since you only have one UI screen to accept a filepath, continue, and abort. The worklist file can be whatever file type you want. I’d say the meat and bones of this problem is finding the right data structure for this file to generalize both tasks.
HARD-MODE
There is a common issue that pops up in lab as well!
Awesome Therapeutics has had issues maintaining tip supply. Hard-coding tips has been a major issue in the past as when a tip type ran out on critical day the handlers were down as they had to be re-programed and re-tested and faith dropped on the robots. Somedays you only have one of the tip types but the means of production must go on! Because of this supply chain issue, Alice and Bob occasionally think they have put the correct tips on the deck when they were just mis-understood. Since the tip boxes are in fact barcoded though… there is really no reason they should need to know right?
Eliminate this common error programmatically!
