I found this thread while encountering a similar problem. @NickHealy_Hamilton posted a clever solution there but I dont think it is a perfect fit for my problem.
The Problem - within a submethod in my library I want to:
Create a new labware a given position (can be done with HSLLabwrAccess - AddLabwareToTemplateSite)
Create a new sequence for the labware (can be done with HSLLabwrAccess - GetDefaultSquenceForLabwareID)
But the crucial piece is that i want the generated sequence to have a dynamically generated name, as opposed to having the submethod output a sequence with a “fixed” name (which I think the example in the linked thread would achieve). For example, I could define an input variable “desired_name” and generate a sequence variable named “seq_{desired_name}”. Is this possible to achieve? Am I missing a tool available in the Sequence and Labwr Libraries?
I want to build a submethod that can be used to generate a tiprack labware in specific positions of my carriers. I had success with the labware generation portion and during testing I was assigning the sequence to a generic holding “sequence variable”. If this submethod were used multiple times within a method to create multiple tip racks and accompanying sequences I would want each sequence to have a meaningful and distinct sequence.
I am interested in creating tipracks dynamically like this to avoid the creation of multiple carriers per method. So if there is a better way to address this root problem I am all ears!
Is your intent to manage the tip racks as individual sequences (one rack per sequence)? Or merge tip racks of same tip type in to a larger category of sequence?
More of the former. Define a tip rack labware in a position on my carrier and define a single sequence that corresponds to that rack that can be referenced in tip pick-up steps later in my method. My layout file would have my tip carriers empty.
Until you find your solution you could try this idea:
Create the tip rack labware
Create the sequences with the desired names and refer to them only when they are needed
Delete the lab ware, leaving the method with invalid sequences
Only load the labware when needed (corresponding to the generated sequences), based on user input/desired name
I don’t know if it will work, since the method now contains invalid sequences, but they are not used, because there is no corresponding lab ware nor pipetting occurring on the unused lab ware and sequences (due to the pre-definition)
For now, I am actually taking a similar approach. I am defining empty sequences for each tip rack position that I then populate if a labware defined in that position. This is ok, but not needing to predefine these sequences or pass these sequences into my sub-method would be awesome.
Smart cookie!
You could also consider altering the HSL code or using PyLabRobot, do what you want there and then convert the language from python to C/HSL code. @Stefan probably has some great ideas here too.
Hope you soon find a more suited solution.
This is an advanced and custom technique, so I’m afraid that you are wading into territory where it will not be possible for me to provide a succinct and simple answer. It is certainly possible to achieve what you want to do in VENUS, but requires usage of more abstract programming techniques.
If you need to dynamically generate an undefined amount of sequences which all need to be managed individually, I would opt for alternative means of sequence data management and not manage then all as individual sequence objects.
Rather, I would dynamically manage the pertinent sequence data for each rack or grouping of racks and their positions with some form of data structure (arrays, dictionaries, files etc) and generate a temp sequence only when needed. The temp sequence can have an arbitrary identifier, and be reused being updated to represent a sequence that fits the particular needs of the command at the time it needs to be called.
You could pull the position and labware data from whatever data structure you have opted for, and use that to construct a temp sequence dynamically. Once you are done using the sequence, its updated position data can be stored back into whatever data structure you have opted for to maintain its status of remaining positions. This will require conversion of sequence data to and from string format.
Another, more simpler option could be to just manage your sequences as elements of an array of sequences, where the numeric element index has some means of linking to the sequences as they are needed. Simply retrieve the needed sequence from the array, use it, and store the updated sequence as an element back in the same index. This is an easy way to manage an undefined amount of dynamically generated sequences which require individual management.
The choice of approach will depend on your specific requirements and application, as well as programming preferences. Hopefully this post can help trigger some ideas. Thanks.