@max - Unfortunately there is no workaround, programmatic or otherwise, that will influence labware detection to reconcile the difference between metal fliptube insert that has a tube or not. The tube detect sensor is mounted to a bracket at the bottom of the autoload, and has no movement control via dedicated motors.
Upon installation, the detector is aligned so that the beam makes contact at a fixed height just below the top surface of the rounded shield mounted to the far left of the autoload assembly. I don’t have the exact height off-hand, but the image to the bottom right makes it pretty clear to reference on your system. As the metal inserts occupy this space, the detector will trigger labware detection for each position an insert is located.
To implement loading of randomly assorted tubes you would need to load and scan all possible carriers/positions that may contain tubes, and parse each position with the consideration that a sample may or may not be present. As you will need to modify error settings and likely need to parse step data for error codes, I recommend using single steps if you aren’t already, as you will want the step data from the load commands (easily parsed with the HSLMlStarStepReturnLib library).
Here are the two main approaches I would consider:
-
Disable labware detection and use detection of scanned barcodes to flag positions as having samples loaded. You would set automatic error recovery of ‘Barcode Error’ to Continue with immediate timeout. Then parse the sequence of all positions scanned for positions that contain barcode data, and then generate a sequence containing only those positions. Alternatively you could parse the step data as well for error codes and barcode data.
-
Treat the insert as a component of the sample tube, and load inserts and samples contemporaneously. Positions without sample tubes would not contain inserts. Use labware detection to flag positions as loaded, followed by parsing of barcodes. Parsing the error codes from the step data will allow for determining positions that contain labware but failed to be scanned, which can then be used to dynamically generate a sequence of positions to be rescanned, and then merged with the other tubes that contained barcode data.
For 32 position carriers, I also recommend slowing down the load speed of the autoload y drive from default for more robust scanning, as the read windows of that tube format are quite narrow. You will need to add a non-default labware property to the sample carriers.
Property key: MlStarBarcodeReadSpeed
Property value: ~500 (default is 1281; 128.1mm/s)
Let me know if you (or others) would like me to follow up with more detail regarding the above.
-Nick