Deck:
Does anyone know how to do this in VENUS? Hamilton run control errors no matter how I hack together a solution:
An error occurred while running Vector.
The error description is:
No solution to transport the labware.
(0x28 - 0x1 - 0x81d)
@ben - This question seems to have a couple different components embedded so I am splitting the response into two parts (directly below this post).
Hope this helps!
-Nick
Edited as I misinterpreted the question - but keeping some additional details for others who may encounter this post
Default waste sequences
VENUS includes ‘special’ labware racks with labware properties that help manage default waste locations for channels and MPH. Selecting ‘default waste’ as a convenience for tip ejects is another way of referencing specific sequences/labware racks that exist on deck, for the steps that support default waste selection. If your deck did not contain the default tip rack waste labware for the gandry components your system is configured with, you would receive an error during analysis, as these are required for each component that could use one on your system.
The reason is because, in the instance the system needs to initialize after a powercycle, and detects the presence of tips remaining on a pipetting device, it is programmed into the firmware for the system to discard the tips before proceeding. During the initialization step, the default locations are the only way to know where on deck to eject, as sequences are not passed into the command. For MPH firmware, it will ‘eject’ to default waste regardless during init.
Regarding default waste labware properties, selecting default waste for tip eject -
will direct the system towards this deck labware, as it has labware properties that designate it as the channel tip waste location.
If this deck labware did not exist, you couldn’t run the method. While can opt to use any custom waste sequence you want, and choose not to use these, they can be convenient when programming in multi layer architecture, as you would not need to pass in a waste sequence as an additional parameter to lower level functions that use it, or maintain it as a separate global sequence.
Typically, default waste modes for sequence designation are only used for tips being ejected off of a pipetting device (channels, MPH96 and MPH384). For waste racks - whether they are spent multiwell plates or empty tip racks going to a waste or designated waste carrier, their waste locations must be defined on deck, taught for intended coordinates and handled programmatically as any other sequence for a get/place plate command.
iSWAP transports
There can be many reasons that an attempted iSWAP rack transport can be improperly configured and result in error. Here are some common ones:
From the trace file screen grab, it appears you are using gold steps. For iSWAP transports, I highly recommend eating the additional line of VENUS and using single steps for get plate and place plate. When troubleshooting an erroneous transport, this will help to deconvolute which labware/transport the system is having an issue with.
Additionally, it is difficult to tell if the off-deck rack positions on your deck layout are within access for the iSWAP on either side of your deck. They would certainly require complex movement for full extension of the iSWAP. My recommendation would be to teach the deck locations of the racks using an rack from the deck location you intend to transport from in your method, taking note of the parameters that allowed for successful teaching. This process is often the key to properly configuring compatible runtime transports, and ensures clean handoffs.
This applies to any on deck off deck iSWAP transport, whether the rack is heading towards a waste, carrier position, or integrated device. The STAR does not care or have different rules for waste racks.
