I would like to use this thread for listing some feature requests. Any further ideas, I will add it to this list.
Currently tested Hamilton Method Editor version: 4.6.0.8061 with Venus-on-Vantage (VoV)
Date: 05.09.22
“Microlab STAR Smart Steps” → “1000µL Channel Pipette - …”: Modifying the aspirate and dispense parameters from static to dynamic. It would be helpful to use variables here. In general: making all such text fields variable.
Find & Replace for variables. It’s very laborious to change the name of a variable and then go through each step to change it respectively. A “find & replace” feature would save a lot of time.
Making “HSL Code” snippets/expressions more dynamic. I.e., declaration and initialization of variables/arrays, indexing of arrays. In general: anything closer to the native HSL/C/C++ syntax.
Undoing (Ctrl + Z) and if possible redoing (Ctrl + Y)
Deletion of unused variables. Variables can quickly pile up in the variables window. Manually going through all unused variables is very laborious.
Option to specify the mixing volume, not absolutely but relatively to the filling volume (estimated by LLD and the well geometry). E.g., instead of “100 µL” mixing volume, “0.5” mixing volume (i.e., 50% of the estimated filling volume).
Aliquot but with dynamic instead of static volumes. E.g. target well A01: 100 µL, target well A02: 200 µL, etc.
Getting rid of “error hiding” problems. E.g., analogous to 7., if you use variable (instead of static) volumes coming from an array in a “Microlab STAR Smart Steps” → “1000µL Channel Pipette - Aliquot” step, this step is ignored during simulation. No error shows up.
Nice-to-have: Debugging (“set trace”) such as in Instinct V
Similarly to the labware teaching procedure, customly instructing the 1000 µL channels, iSWAP, 96-Head or CO-RE Gripper to move to a target location. E.g., well H05 at bottom rel. distance 2 mm w/ channel 5. Ideally while specifying the movement speed to prevent collisions.
Realistic collision detection and prevention
Nice-to-have: Option to aspirate/dispense custom volumes of air without having to use dummy sequences
Nice-to-have: Simulator showing liquid levels in all cavities
Option to find text inside the trace view (Ctrl + F)
Option to accelerate the simulation even more and option to skip the visual simulation and just show the traces
I’m hopeful that Hamilton will have a look and eventually implement some of these. Thanks in advance for listening to us.
Tip reloading built into the standard Tip Counting library (this whole library could use a refresh)
Autoload homes at the far right track after init. Why is is still blocking tracks 1-5 after init? Doesn’t it want to go home? Is it too good for its home?
Trace Grouping notes as comments just like the Trace Comment checkbox
Greatly appreciate all the feedback and I encourage all to submit more to this thread. I am sharing the forum posts with Hamilton product management. We are actively working on substantial revisions to the VENUS software - hope to have more of a significant update by SLAS 2023 for our first phase and beyond. I think it would be great to use this forum to also share such updates and confirm what feedback will be incorporated and when.
What I’d like to see are improvement to error handling/recovery options. E.g. after the instrument crashes, be able to click back multiple steps in order to recover during runtime or make it possible to switch between simulation/real-time midway through a run.
The ability to run command-line scripts with arguments.
A VENUS work-list that is well documented such that web-applets can produce such a file. This is inspired by this very mysterious dead function in the ML_STAR library called HSLML_STAR::ExecuteWorklist that is expecting a “Gemini Worklist File Schema”. When you click help, no explanation is given on this schema except a screenshot of worksheet from a 91’ Excel spreadsheet.
Example based documentation in the help docs
YAML Library
Allow recursion in function calls
Define labware using a well-defined JSON schema.
Autoload reads barcodes for empty plate carriers and records observed barcodes and the positions plates were found in.
Create sequences at run time and not have to have empty sequences in a deck layout file a priori to hit SequenceCopy a bunch of times.
Error in simulation if an arm attempts to access tracks it can’t access in real life
Those fields are optional and only for manually selecting a liquid class. If you use a variable for the liquid class name it will determine that information strictly from the liquid class.
Edit: To further clarify, these fields are filtering options, so they are used to drill down to a specific liquid class rather than displaying all possible liquid classes to the user. Therefore they are not used in processing, all information comes from the liquid class name itself.
The tip type and dispense mode drop-downs are just filters for the Liquid class input so they can’t accept variables. However, you can put a variable into the Liquid class input that uses any tip type or dispense mode which bypasses or overrules whatever is set in the filters.
So you can leave the filters as the default and assign different liquid classes representing different tip sizes, modes, etc. Just be sure you use the right tip size sequence and volume range, which can also be set as variables!
A good library for loading dialogs. I haven’t seen any solution that really convinced me. Key is that it should be visual and show all relevant information in a clean way. Instinct had some good ideas in this regard, but was way to cluttered. Maybe a way to add information to a 3D view deck layout.
Ability to dynamically generate custom dialogs. In its most simple form an import function for XAML files could already help.
Allow expressions in all input fields
Some basic code highlighting for HSL code blocks
New logging system to replace trace files. Something thats is more searchable and can be filtered. A bit like what Instinct had, but I wasn’t a huge fan of the visuals
Just overall better documentation. There are so many things that are so badly (or not at all) documented…
Teach multiple positions in one go, without having to put down the tip first
When you click OK during teaching, transfer the value directly to the dialog and not only after the tip was returned
One more vote for the UNDO function in the method editor.
Maybe there is a way to include more validation options into user dialogs, e.g. a sum of two fields must be <= 96 or entry must follow a defined RegEx. Currently, the dialog must be placed into a loop together with those checks, resulting in a short disappearence of the dialog window.
and an easy way to include functionality written in other languages like C# or C++, e.g. provided as .dll would be nice.
I just wanted to touch on a few items mentioned here to see if these features were just not well known or if they are simply lacking for your needs:
It would be helpful if we had more details on the definition of a “native recovery” @mojo - any additional information you can supply would be great.
Custom Dialogs already let you export/import them as XAML files for editing and re-import. Unfortunately you cannot attach back-end code (e.g. C#) to the dialogs as you would a WPF project, but if it’s strictly XAML, take a look at the Import/Export functions in the Custom Dialog UI (top left when editing a dialog). Now, if you wanted to generate/import these dynamically at runtime (rather than set one up in the Method) then that is not a current feature.
@benjaminwohl have you tried all of the Visual libraries @EricSindelar_Hamilton posted here in the past few days? A number of them are very similar to what you described, but if they fall short, understanding what they lack would help in improving them.
Custom Dialog text input fields support RegEx. You can use some of the defaults or type in the expression yourself. Please let me know if you would like additional information.
Some examples of poorly documented components would be helpful. Perhaps the Help file isn’t as easily accessible or the contents are insufficient - knowing more details as to what makes them badly documented would help us improve them!
If these items informed you of a feature you were unaware of that fits your needs, great, but otherwise if you can provide additional feedback on why they did not meet your needs, that would be greatly appreciated.
@WilliamCham_Hamilton I was referring to a “recover” option during run time, so that any runs that abort can be restarted from the point at which they left off. For instance, remembering variable assignments from the last run, or that x plate was moved to y position, without having to build workarounds into the method.
This is a great thread, and the fact that employees from Hamilton are here and taking on board these requests is absolultely amazing. It is very much appreciated. Thank you.
I have a couple of suggestions that would enable better testing of methods:
Parameterised method runs: as I’ve asked on a different topic, it would be nice to be able to parameterise inputs into a method when using hxrun.exe. This would help with automated testing etc. I understand that there are often workarounds but these aren’t optimal.
Containerised + commandline/headless venus: for testing, it would be nice to have a containerised version (like docker) which is truly headless. In combination with the above, inputs normally given through dialog boxes can be instead passed through parameters which means dialogs can be suppressed.
Some other suggestions:
Better documentation of HSL: it would be nice to have documentation regarding Hx* objects etc.
Better integration for and First-party version control: Generated HSL files have comments for each step with the appropriate line numbers in the method file. If a step is inserted in the method file near the top, every comment in the hsl file for the steps below it also change, which throw off diffs. It is also impossible at the moment to merge method files. If this can be improved, that would be fantastic. Furthermore, if there is first-party integration with git/svn (git if possible), then that would improve version handling etc.
I am sure I will think of more but these are a few for now!
Better compatibility with high resolution screens. I increasingly see 2k, UHD, and 4k screens being used in the office and lab. Personally when I do simulation testing with a UHD screen laptop the timer popups don’t show up.
I am aware of the published Windows 10 Menu Scaling Correction solution from Hamilton, and it helps resolve the timer issue but I am left with tiny icons/buttons in Venus even with Large Buttons setting enabled.
