Delacor Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

error propagation across subsequent requests

Solved!
Go to solution

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

 

0 Kudos
Message 1 of 17
(653 Views)

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

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
0 Kudos
Message 2 of 17
(619 Views)

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.

 

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
0 Kudos
Message 3 of 17
(614 Views)

You're doing something wrong, but we can't tell without seeing some code.

0 Kudos
Message 4 of 17
(610 Views)

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

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au
Message 5 of 17
(605 Views)

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.

0 Kudos
Message 6 of 17
(579 Views)

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):upstream_request.PNG

 

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):

 

r&r.PNG

 

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.

 

 

 

 

 

0 Kudos
Message 7 of 17
(576 Views)

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

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au
0 Kudos
Message 8 of 17
(573 Views)

@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?

0 Kudos
Message 9 of 17
(559 Views)

@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.

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
0 Kudos
Message 10 of 17
(553 Views)