Hey All,
Is there a way to determine which errors are reported by Email? I can get it to email on certain errors but not others; specifically, it seems like only ML.STAR errors step errors are reported, whereas code related errors (e.g., left hand side not a number and such) are not.
Thanks!
Gil
Hi Gil,
The send email on error feature enabled in system configuration editor is designed to only send automatic emails when waiting error dialogs are produced on ML_STAR and other device steps configured as a deck instrument.
To have Run Control send emails on other occurrences, you can use the âSend Emailâ function of the HSLUtilLib library, which is default to all VENUS installations. The function is straightforward, only needing string variables/values as parameters for recipient address, subject and body.
This function is configured to use the same sender and SMTP settings that you already have specified in configuration editor used to send emails on error, unless you use functions within the library to temporarily overwrite those settings.
This function can be called programmatically whenever you want, whether in error handling situations or OnAbort.
For sending emails with the intent to capture programmatic errors or bugs, I recommend using the function âErrGetDescriptionâ of the HSLErrLib library (also default) prior to the SendEmail function. This command will return a string whose value will contain a description of whatever the active/current error object is. This can be used as the body of the email to capture details.
There are no parameters, just a return value.
Thanks.
-Nick
This is great. Thank you Nick!
Hi @NickHealy_Hamilton ,
Quick question regarding this. In the âtoâ parameter, is there a way to list multiple email addresses? Or will this only work with one email?
Same question applies to email address setting in the system configuration settings.
I ask since our SMTP will work fine with single email address, but our internal SMTP system wonât work with email distribution lists.
If not, itâs not the end of the world, as I can get around this by setting up some outlook filtering rules to automatically forward the emails to the relevant other people as necessary.
Thanks!
You can provide all the emails as a string
Mail1,mail2,mail3mail4 and then use string lib from HSLExtentions to split the string to an array with the de limiter you use.
Then get size of the array, loop that amount of time and use the mail addresses youâve split to this array per loop. So each index will be used.
Sending emails to any number of users that way. Otherwise you can do the same with MailAlert or similar. However in Venus 6 it works great.
Not for the default error handling emails (the one you set in system config). Youâd have to deal with the sending of emails yourself if you wanted to split on a delimiter.
I could never find a way to designate multiple emails, so weâve gone with a distribution list.
Hi Nick, do you have a list of waiting error dialogs that I can use as a reference? Also whatâs the difference between a waiting error dialog vs other error types? Iâve been testing automated error emails on our Vantage. It looks like the waiting error dialogs + emails only appear in some instances (iSWAP get plate command when no plate is present) but not others (cLLD failed to detect liquid but error recovery on, thermomixer errors). Currently, it looks like I will need to test all devices/error types to determine which will generate an automated email vs. which I will need to put in a custom error handler and send a notification via HSLUtilLib. How have others on the forum managed to catch errors and notify the operator/group?
Hi Paul,
Waiting errors can be considered as any time an instrument error results in a hang in method execution, displaying an error dialog offering recovery options for one or more qualified error categories mapped to the affected instrument step. In other words, any error dialog that looks like the one below:
For a step or command to be eligible for mapped error dialogs, they must be from a Hamilton device category using a dependent step from the editor tool box. All VENUS platforms will have at least a pipettor device category (âML_STARâ for STAR and VANTAGE and âNIMBUSâ for NIMBUS) but there may be additional system devices depending on the install in question. All possible system devices that will produce waiting errors for any recoverable error will have itâs own category in system configuration editor, as an eligible device that can be added to a decklayoutâs system collection (which exposes these commands for any method bound to the deck)
In order for the error to qualify as a waiting error (and trigger an email event managed automatically via system configuration setting) the error recovery dialog must actually be displayed and interrupt run execution for the method or task affected.
That is to say, that if you use automatically configured error handling for a particular mapped error category for an instrument step, and the autoconfigured recovery execution allows the step to complete, then no waiting error will be displayed and no email will be generated automatically.
In the above example, a MPH96 aspiration step is has an autoconfigured recovery option to attempt one ârepeatâ in the instance of an âinsufficient liquid errorâ. If that fails, then the execution flow will move to the second recovery, which in this case is toggled to âShow infinite dialogâ. In this case, you will have a waiting error, a displayed recovery dialog and an auto sent email.
Waiting errors and auto emails will also be suppressed if the error recovery is set to âCancelâ in order to execute a customer error handler block if present.
Device driver commands will not be eligible to recovery dialogs, as their errors cannot map to the characterized error categories of a Hamilton system device. In those cases, you will need to use programmatically sent emails via the HSLUtil library.
Thanks.
-Nick
This explains it perfectly, thanks Nick!
Hey Gil,
Yeah, Iâve noticed the same behavior in some setups â typically, email notifications are triggered by higher-level step errors (like ML.STAR failures), but not always by syntax or code-level issues.
From what Iâve seen, some environments suppress lower-level scripting errors in notifications unless they explicitly halt the run. You might want to check if the logging settings or error-handling configuration in your workflow has options for âsilentâ vs. âcriticalâ failures.
Also, wrapping critical code blocks in a custom error handler can sometimes help flag and escalate these kinds of issues via email.
Hope that helps a bit!
