Nearly every Venus method I make takes user parameters that influence how the user needs to load the deck. For example, maybe the users is specifying they are loading two plates for a bead cleanup, this means my method will expect two tip racks.
Right now, I communicate these variable deck layout configurations with sometimes dozens of flags that control whether certain visual elements show up within dialog boxes (“visible” property taking “in” my “flag_Show2TipBoxes”). These dialog boxes contain the visuals users will rely on to load the deck correctly.
Does anyone handle/create reactive reactive deck layout graphics in other ways? Are there libraries to help with this? Are there known tricks to make this work less tedious/error prone?
I do not exactly know what a solution would look like, I am just interested in hearing how people handle this step of the development process.
Huh, I’m not sure I’ve done dozens of flags for deck setup. Usually I have two flags, the text of what’s supposed to be loaded and the string of the deck loading image.
What I usually do is have an array of deck loading text that is passed to a temp var into the dialog, and another array of deck image string that is passed to a temp var into the dialog. Which index of the array that is selected is determined by the operator when they set up their run. For the image in dialog prompts you can load several images and the temp var can decide what image to display. This has worked well for me and has simplified the programming spaghetti.
EDIT: To add, I’ve also broken up the deck loading by carrier, tip carriers and then each plate carrier one at a time. That way the operator isn’t too confused with all the deck loading that’s happening at once.
I’ll save you some heartache. Use python to create a reactive deck loading dialog. Venus dialogs are just not advanced enough. You’ll be much happier
You may want to check out the Deck Loading Instructions smt library that @BrandonBare_Hamilton authored which can dynamically create custom dialogs in VENUS. The function reads through the deck layout and parses out all the carriers and labware that are on the carriers. The functions will display the carriers on the deck and labware that is loaded on them via custom dialogs.
Generally speaking though, I highly recommend reviewing input and output dialogs with the users who will have to interface with them every day. One can spend a lot of effort making great-looking and functional dialogs only to have them not meet their needs. Sometimes a balance must be found between too many or too few dialogs, too much or too little information, supportability, etc. It can vary quite a lot, but fortunately, the custom dialog editor in VENUS provides a lot of options.
One approach that I often implement that is easy to make and modify later is to have a picture of the system deck and numbers as images (rather than embed graphics with the system deck image). Then a simple text field is added to provide more detail. Using numbers as images and the text box makes modification simple and more supportable - especially if you are still in development mode and changes are likely to occur.
I’ve uploaded a zip file containing a bunch of numbers with different colors and drop downs in case others might find it useful.
Interested to hear about other solutions people have worked on!
Using arrays is an interesting approach that would work nicely with some of my methods. If I am understanding correctly, you would have a pregenerated image of all your deck confirmations in this implementation. I have some methods that have > 2^7 possible combinations of deck layouts so using pregenerated images is not feasible. However, I currently show the entire deck in one graphic for the user. Breaking up the loading by carrier would drastically reduce the possible combinations.
Do have any resources or tips on what this implementation would look like? Any helpful libraries? I am very interested in a solution like this but would not know exactly where to begin. Have you built this tool in the past?
Thank you! Looking at the library now.
@EricSindelar_Hamilton do you happen to have an example method that utilizes this library you are able to share? No worries if not.
See this link for a Deck Loading instructions demo method.
This .pkg only seems to import a .lay file (‘Deck Loading Instructions Example.lay’) and no method. I do get a warning that the package might not run on my version of Venus, maybe related? My colleague confirmed that she also only gets the .lay (she is on the same version of Venus as me).
Sorry for taking more of your time.
Hi @djunk ,
When you import the pkg and receive that warning, do you tell it to continue or to abort?
As long as you import using recovery mode and specify no to all for overwrite, the Method and Layout as well as libraries used will import just fine despite being exported from a newer version as long as you continue. The method will import to the same directory as the library.
Please direct message me if you continue to be missing the method files.
This worked. Thank you @BrandonBare_Hamilton . I was not importing in recovery mode but doing that seemed to be the fix.
Yeah! You got the idea! Breaking up the loading by carrier would help eliminate the error where the operator that forgets to load that labware in the far off corner. It can also help with supporting the method, say you need to update the deck loading image or instructions, and since you broke up the loading, you just change the one prompt/image that’s affected, and you can leave the rest the same. However when you’re making a lot of changes it can get hard to keep track.
Either way you choose there’s an upfront amount of work you need to sink in,: taking images, editing images, and prompts. All approaches require work to get started. Try some and see what you and your operators like before choosing one approach and sticking with it.
I used python dash (This is the easy part…) to create a reactive webpage to simplify loading. I have the Vantage autoload remove a carrier then the loading dialog will show. Each position on the carrier has additional information as needed. Once the user accepts the loading I use a height test to ensure the correct labware was loaded (Our lab does not use barcoding effectively yet…) and use pressure LLD to confirm the volume is as expected.
For those resorting to python etc,would it be possible for you to show the loading prompts youre making? I genuinely haven’t found a need to go outside of the Venus dialog maker. Although it would be nice to be able to trigger flashing of different labware when events such as buttons are pressed…
Just to keep topics organized on the forum, could the python approach be posted in its respective subcategory? The link to the thread can be posted here for context.
Sure, let’s keep the discussion to Venus on this thread.
@BirdBare if you want you could make a new thread for your interface
I’ll see if I can cannibalize the dialogs for sharing. This is a proprietary dialog design within our company so sharing would be strictly prohibited. Once I know what I can share I will create the associated thread, unless of course someone else makes it first.