02-26-2019 05:36 AM
Dear DQMH community,
I am successfully (and happily) using the DQMH framework to create a LabVIEW-based scripting tool for an experimental station where users want to acquire and store various kinds of signals as a functions of different control parameters (and variable and complex combinations of the latter). Each instrument is a DQMH module with proper acquisition/configuration/action requests. Whenever users need to integrate another instrument I just add a module and voilà, users can integrate the new functionality in their scripts. So, thanks a lot, once again, for this great tool!
Now to my question.
The user scripts consist of sequences of "Request and Wait for Reply" VIs from the various modules.
Imagine that, for instance, one acquisition module returns an Error 56 due to a communication timeout with an instrument due to some problem. Now, the Error 56 goes into the next request VI, the Obtain Notifier (DQMH_OBTAIN) returns an invalid Refnum (since it has an incoming error I guess), and eventually the Release Notifier VI that receives this invalid Refnum raises an Error 1, halting the execution of the whole script with an "Error 1" popup dialog since its error terminal is unwired.
So, here comes my question/observation: this approach has the bad effect of hiding the (important and meaningful!) upstream error from the user, since he/she only sees a cryptic "Error 1" on a Release Notifier (actually a red herring), and has no idea that actually this was simply originated, for instance, by a simple, upstream instrument timeout unless he restarts the script and goes probing around the error wires (and the timeout, which might be a rare, pathological event, needs to happen again...).
Is this a "bug" or is it something I'm missing in DQMH due to some poor coding on my side? Why are the error terminals of the Release Notifier left unwired?
Thank you in anticipation!
Carlo
Solved! Go to Solution.
02-26-2019 11:05 AM
Hi Carlo,
Glad you are liking DQMH and that is working well for you.
Do you mind attaching a picture of the code? Also, please confirm what version of DQMH you are using. We used to not propagate the error from the reply, but it is now part of the "DQMH Request and Reply", I just want to make sure you are using a version that includes that.
Thanks,
Fab
02-26-2019 11:38 AM
Without looking at any code, it sounds like you have automatic error handling turned on. I would personally recommend against that. Although if you do some research you will find a variety of rather strong opinions on this both for and against.
As for not wiring out the error on a destroy reference, often it is not wired because we don't care about the error. Generally, the only thing that can go wrong closing a ref is that it doesn't exist. In that case, we really don't care because we want it to go away anyway.
Again not looking at the code my guess (only because I know Fab and she is very thorough) is that DQMH is not "losing" the timeout error 56, but rather the automatic error handling routine is preempting it. If you turn automatic error handling off my guess is that error will continue until you handle it somewhere. Since you are using automatic error handling you may not be handling fully propagated errors, but you should be regardless.
Wiring the error out of the destroy ref to something (usually an input tunnel on a case structure or a clear errors) should cause the automatic error handling not to pick up that particular error without propagating it down the error chain.
02-26-2019 12:56 PM
You're doing something wrong, but we can't tell without seeing some code.
02-26-2019 02:36 PM - edited 02-26-2019 02:38 PM
Hi Carlo,
One thing to be mindful of is the timeout of the Request and Wait For Reply. This is by default, 5 seconds. If your DQMH module (that had the 56 error) took longer than 5 seconds, then in actual fact the calling VI will continue on after 5 seconds and the Request and Wait Fore Reply VI WILL NOT output an error (but the Timeout Boolean will be true), so you may not actually be seeing the 56 error in the calling VI.
I have been in discussions with Fab about the possibility of the Request and Wait For Reply VI changing to produce an error on a timeout, but there are some complications with this, so it is still in discussion. MY workaround is I have a VI called "Generate Error From Timeout.vi", which I place after each Request and Wait For Reply call.
Consider the default 5 seconds delay, and adjust it if you need more time (although it is global to the whole DQMH module, so you may need to have a specific timeout for each Request and Wait For Reply.
Hope this helps!
Cheers
02-27-2019 05:00 AM
I recommend you guys always treat a timeout waiting for a reply as a failure (thus error). All Modules should commit to replying in a reasonable period of time ("reasonable" being dependant on the application) and timeout values should be comfortably larger than that reasonable time. Otherwise you turn any simple interaction into something requiring much more complex logic.
02-27-2019 05:26 AM
Hi everyone, and thanks for the many replies and comments. Here below are my replies and considerations.
@Fab: the events were created with DQMH 4.1 (now I've updated to 4.2). The code is not much informative I guess, but here it follows. This is simply the code for the Request that generates the Error 56 (at the terminal indicated in red):
and here is the part of the subsequent Request and Wait for Reply VI that I'm referring to (specifically, the Release Notifier on the right that generates the Error 1):
The error is obviously propagated from the first request to the subsequent one, but then it gets "silenced" by the Error 1 of the Release Notifier (or better, the handling of the Error 56 is postponed).
@Taggart: yes, Automatic Error Handling is turned on, but that's both my choice and DQMH's choice (the Request VI with AEH turned on was generated by DQMH, not me). Personally I would be very skeptic about globally turning off AEH in my environment, (feels like debugging will turn into a nightmare).
DQMH made a choice not to wire that destroy ref error to anything (and left AEH on): this leads the default behavior that I described: the "true" Error 56 being "preempted" (call it as you wish) by the Error 1. And it is effectively silenced, because in a chain of Requests you will only see a chain of Error 1 popups until the end of the chain (or until it is explicitly handled). This choice of not wiring that error in and out is what I'm asking about in my question (why, and how do DQMH people deal with the behavior I described).
@drjdpowell: above you can see the code, but I'm mostly talking about the DQMH-generated VI.
@Ozfarmboy: no, the Request timeout is not an issue here (the internal data acquisition VI times out at 1sec, and spits the Error 56)
Thanks again! If you need more info, just ask me.
02-27-2019 05:49 AM
Carlo,
Error 1 coming out of Release Notifier, means that the notifier is not valid, or doesn't exist. It's like the notifier has either already been released, or wasn't created in the first place.
I just put the Release Notifier into a blank VI, and got Error 1 when I ran it.
Regards
02-27-2019 08:49 AM
@carlod80 wrote:
but then it gets "silenced" by the Error 1 of the Release Notifier
That doesn't make sense. Error-In always takes precedence over internal errors. What do you mean?
02-27-2019 09:01 AM
@Dr Powell there is no error in wired to the Destroy Notifier. I believe he is referring to the fact that automatic error handling is occurring before his other code.
@ Carlo - That's interesting. I seem to be able to debug just fine without automatic error handling.