DVR Error Handling

[mje]

I'm just finally getting enough time on my hands that I can explore DVRs. I think I'm missing something with respect to error handling and I'm hoping someone can enlighten me. See below:

My first thought when I tried wiring this up was of the whiskey tango foxtrot variety, and well...it still is.

The process of taking in a DVR, checking for an error, deserializing contained value, operating, then reversing the process is inherently...serial. Why is the error handling so discontinuous? Why doesn't anything have error in terminals which forces me to bundle 3 values together each time I need to operate on the DVR? This seems unnecessarily messy and inelegant. Am I missing something?

[Jarrod S]

I'm just finally getting enough time on my hands that I can explore DVRs. I think I'm missing something with respect to error handling and I'm hoping someone can enlighten me. See below:

My first thought when I tried wiring this up was of the whiskey tango foxtrot variety, and well...it still is.

The process of taking in a DVR, checking for an error, deserializing contained value, operating, then reversing the process is inherently...serial. Why is the error handling so discontinuous? Why doesn't anything have error in terminals which forces me to bundle 3 values together each time I need to operate on the DVR? This seems unnecessarily messy and inelegant. Am I missing something?

I agree it's terrible usability. But I think the reasoning behind it may be functionality-related. Usually nodes that have an error passed in are a no-op. What happens if the left DVR node has an error passed into it? Does it dereference the value? Does it output a default value and leave the reference alone? Even more questionable is what happens if the right DVR node has an error passed into it. What happens then? Do we leave the DVR open, because the close operation doesn't happen? Is the value ignored?

Ideally I would like these nodes to have error inputs, but they have no change in behavior when an error is passed in. From a usability and inplaceness perspective that is best. That, however, is completely different than any other function.

[jgcode]

I'm just finally getting enough time on my hands that I can explore DVRs. I think I'm missing something with respect to error handling and I'm hoping someone can enlighten me. See below:

My first thought when I tried wiring this up was of the whiskey tango foxtrot variety, and well...it still is.

The process of taking in a DVR, checking for an error, deserializing contained value, operating, then reversing the process is inherently...serial. Why is the error handling so discontinuous? Why doesn't anything have error in terminals which forces me to bundle 3 values together each time I need to operate on the DVR? This seems unnecessarily messy and inelegant. Am I missing something?

Well technically you don't have to merge the error in wire as you have the case structure catching any errors... but I know what you mean.

I would like a single class method to accept DVRs.

That way I would only have to create one method for ByVal that I can use ByRef

If I wanted to string together a bunch of methods inplace then I would use the IPE and suffer the wrath of size on the BD and the error handing

Right now I have create another VI just if I want to read one method and it is a PITA.

I understand about the consequences, and I want the option.

Please vote here to get this one through into 2010!

[mje]

Well, even though there's no error for the input, I still merge because if I recall there are some legacy VIs can issue a warning...error is false but a code exists. Hence I think it's always important to propagate a no error condition (or am I imagining things?).

Jarrod's comments make sense though, I think I might have to agree now with the current design. However:

If the left DVR node fails to get the value for whatever reason, I'd expect a default value to be returned, analogous to overstepping an array. I don't think it would be a big stretch to expect the same behavior with respect to an error condition. BUT...as Jarrod said, the real question is what happens on the right node. This node must always attempt to execute, otherwise all sorts of bad synchronization things can happen. The error in functionality makes no sense for this node...if you don't replace the value, most programs would enter an undefined state, probably a deadlock since NO task would ever be able to retrieve the value afterwords if the value is never re-referenced.

So I guess after more careful consideration, I think the nodes are designed exactly the way they have to be designed.

[jgcode]

Well, even though there's no error for the input, I still merge because if I recall there are some legacy VIs can issue a warning...error is false but a code exists. Hence I think it's always important to propagate a no error condition (or am I imagining things?).

Great point, but for me I don't normally have a system in place for trapping, reporting and logging warnings though, only errors.

So I guess after more careful consideration, I think the nodes are designed exactly the way they have to be designed.

Yes, there are designed correctly, IMO that same design should be used when a DVR is connected to a class method, but (the merging etc) should all take place behind the scenes. This is a specific use case, but that has come up frequently for me.

[Daklu]

The process of taking in a DVR, checking for an error, deserializing contained value, operating, then reversing the process is inherently...serial.

FYI, when DVRs were first released there was an example posted by an NI employee and some discussion about the error handling. As I recall the example completely ignored one of the IPE error outputs because it would never generate one in that code. The details (and the a link to the thread) escape me at the moment.

I did find this thread with DVR error information from AQ...

> I'm not sure what kind of errors will be generated by the IPE read and write node.

The only one is "invalid reference". The Close Reference node actually waits for all current IPE structures, so there is no async delete to worry about, but you can have a Not A Refnum or a refnum that has already been Close, or a refnum that was created by someone casting some random integer into a refnum -- any case where the unlock tries to unlock an invalid refnum creates an error that needs reporting.

[Djed]

The two error terminals of the read/write (lock/unlock) dvr border nodes deliver identical errors. Thus, it is never necessary to "tunnel out" the errors from the lock/read border node as done in the first post's code. Also, technically the write/unlock node does nothing but release the DVR's lock and thus cannot return any new error.

As for the lack of input error terminals, there was confusion as to what the behavior would be if an error were wired into the read/lock DVR border node (the write/unlock would continue to simply release the lock). Should the nodes ignore the error but add it to the error out? Should they not lock the reference but instead create a default value on the wire? mje has a good discussion. In the end, even if perhaps it wasn't the most usable design, we wanted the behavior to be clear for the nodes, so we omitted the error-in terminal.

[Aristos Queue]

To add to DJed's post:

In the particular example posted, you don't need the Merge Errors.vi at all because there's no reason to merge a guaranteed "no error" with the other error stream.

Also, technically the write/unlock node does nothing but release the DVR's lock and thus cannot return any new error.

Or, to phrase it another way: BOTH "ERROR OUT" TERMINALS RETURN THE SAME VALUE. So you never have to merge these two error streams. Automatic error handling is satisfied if you wire either one of these two error terminals.

[mje]

...technically the write/unlock node does nothing but release the DVR's lock and thus cannot return any new error.

Very good to know. So essentially the only time the unlock fails is if the lock has previously failed (with the same error). Thanks for clarifying.

Automatic error handling is satisfied if you wire either one of these two error terminals.

I find this statement however implies behavior I'd not expect from LabVIEW...are you implying that in this case, if auto handling is enabled and you have an unwired error terminal on an IPE node whose mated side *is* wired, LV won't automagically halt execution when an error is generated? Does this apply for variants as well as DVR nodes?

[Aristos Queue]

I find this statement however implies behavior I'd not expect from LabVIEW...are you implying that in this case, if auto handling is enabled and you have an unwired error terminal on an IPE node whose mated side *is* wired, LV won't automagically halt execution when an error is generated? Does this apply for variants as well as DVR nodes?

Variants? I have no idea what you're talking about. But, yes, you have the behavior correct. Those two error terminals are the same error, just available at two different locations on the node -- where "node" in this case means the combined pair of the DVR read and DVR write.

[jgcode]

To add to DJed's post:

In the particular example posted, you don't need the Merge Errors.vi at all because there's no reason to merge a guaranteed "no error" with the other error stream.

Or, to phrase it another way: BOTH "ERROR OUT" TERMINALS RETURN THE SAME VALUE. So you never have to merge these two error streams. Automatic error handling is satisfied if you wire either one of these two error terminals.

Cool - I did not know that.

If we only have to merge once - should we choose the In or the Out (is there any benefit of one over the other)?

And what about the case with multiple DVRs on a single IPE?

[mike5]

And another question: If the DVR-in fails, is the in-place element skipped, or do I have to use the error wire to "skip" the code in the element?

Miha

[Djed]

Yes, I believe the variant bordernodes treat errors in the same way (for the same reason as DVRs).

No, I don't think it makes any difference on LabVIEW's side which error-out terminal you wire. All things being equal, I'd recommend using the one inside the structure if you are doing something inside the structure, and the one outside the IPE structure if you are just merging the error (or presumably the warning) from outside.

Each bordernode (whether data value reference or other) on the IPE structure acts independently (with the exception of order of execution which is ordered to prevent deadlocks). Thus, each pair of bordernodes generates a single, unique error which may or may not be handled. If you wire one pair of bordernodes, but not the error terminals for the other pair, you could trigger auto error handling. Each read/write pair can generate its own errors depending on the state of THAT reference.

Since any number of bordernodes could be present, as well as any number of calculations could be done inside the IPE structure, we do not "fail" out on the IPE. If a data value reference has an error accessing the reference (a fail other than just a wait until the lock is available), a default value is placed on the de-referenced wire. All other calculations in the IPE are performed as usual and we simply discard the value wired to the write/unlock bordernode for the DVR with an error. If you are doing a calculation that takes time or referencing a data value reference that is likely to fail, I highly recommend putting a case structure inside the IPE and act according to whether the border nodes have an error. Actually, this is part of why we don't have an error-in terminal on the bordernodes, because even if they individually fail, the structure continues. Forcing one of them to "take a fall" because of an external error didn't seem to be the appropriate behavior.

Edited March 23, 2010 by Djed

[Yair]

If a data value reference has an error accessing the reference..., a default value is placed on the de-referenced wire.

Does that mean that there's a new buffer allocation?

Presumably such an allocation won't be a big hit, since default data usually doesn't take up much space, but it is a thing to consider if handling large data structures.

[Aristos Queue]

Does that mean that there's a new buffer allocation?

I went and asked. Here's the details:

The Read Reference node of the IPE always has a buffer allocation standing by in case the data value reference coming in is invalid. So the code inside the structure is pointed either at the data brought in by the reference or the local allocation. The local allocation is initialized with the type's default value whenever it is needed. If we did an on-the-fly allocation, we'd have two problems: data allocations in RT (where, believe it or not, DVRs are actually safe to use as long as you guarantee there's no contention for them, so you can use them for the "guarantee no data copies use case") and complex logic for tracking when to deallocate an on-the-fly allocation.

Top-level data size for the default value is generally small, so it really isn't worth worrying about most of the time -- you'd have to have a giant cluster of many many doubles to get significant top-level data size.

[Yair]

...you'd have to have a giant cluster of many many doubles to get significant top-level data size.

Or a typedef with a large default value? I don't think I would have one, but I could envision someone creating this data as default to avoid having to allocate it explicitly.

[Shaun Hayward]

Or a typedef with a large default value? I don't think I would have one, but I could envision someone creating this data as default to avoid having to allocate it explicitly.

Although, and I right in presuming that if one were using an object instead of a regular cluster, even if the defaults were large strings / arrays, the additional memory allocation would only be 1 pointer-sized int?

Edited March 24, 2010 by Shaun Hayward

[Aristos Queue]

Or a typedef with a large default value? I don't think I would have one, but I could envision someone creating this data as default to avoid having to allocate it explicitly.

No. A terminal whose type is a typedef does not get the typedef's default value as its default value. So if you have a typedef of an Int32 whose default value is 5 and you put that inside a For Loop and tell it to execute zero times, the value you'll get out is 0, not 5. Typedefs define a type, but they do not define all the behaviors of that type. The default value set on the FP of the control editor is just the default value of any controls of the typedef. If you need a type where the default value is actually defined as part of the type, you need a LabVIEW class.

Although, and I right in presuming that if one were using an object instead of a regular cluster, even if the defaults were large strings / arrays, the additional memory allocation would only be 1 pointer-sized int?

Yes. And that one pointer would point back to the master copy of the class' default value.

[David Vanleeuwen]

On 3/22/2010 at 4:19 PM, Aristos Queue said:

To add to DJed's post:

In the particular example posted, you don't need the Merge Errors.vi at all because there's no reason to merge a guaranteed "no error" with the other error stream.

Or, to phrase it another way: BOTH "ERROR OUT" TERMINALS RETURN THE SAME VALUE. So you never have to merge these two error streams. Automatic error handling is satisfied if you wire either one of these two error terminals.

The comment that the automatic error handling is satisfied if one of the two terminals is connected seems incorrect. Please see the image below. I have tested this both in 2015 and 2017.

 

The errors are the same at this point in time, but I don't think there's any guarantee that that will not change in the future. I plan to always connect both.

[TomOrr0W]

Hi David,

I tested this on some versions I have access to:

2009: No Error Prompt (Yes, I double-checked that Automatic Error Handling was turned on)

2015: Error Prompt Appears

2017: Error Prompt Appears

2018: Error Prompt Appears

[Aristos Queue]

Quote

The errors are the same at this point in time, but I don't think there's any guarantee that that will not change in the future. I plan to always connect both.

Yes, there is a guarantee: both a statement from R&D and also just how much code we'd break if that ever changed. But if you want to continue connecting both, it's just your own programming time and run-time performance you're wasting, so go for it. 

Quote

The comment that the automatic error handling is satisfied if one of the two terminals is connected seems incorrect. Please see the image below. I have tested this both in 2015 and 2017.

I'll file the bug report. Definitely worked when the feature was first introduced (thanks to TomOrr0W for checking back to 2009). *head bang*

This has not been a good LabVIEW day. 

[Ernesto Aneiros]

11 hours ago, Aristos Queue said:

Yes, there is a guarantee: both a statement from R&D...

As we have already seen, a statement from R&D is not a strong guarantee.

11 hours ago, Aristos Queue said:

But if you want to continue connecting both, it's just your own programming time and run-time performance you're wasting, so go for it. 

I also plan to connect both not because I like wasting my own programming time (as negligible as connecting an extra terminal might be) but because LV's behavior here is _inconsistent_ between versions and _silently_ changed. What guarantees do we have that it will not change again?

[Neil Pate]

50 minutes ago, Ernesto Aneiros said:

As we have already seen, a statement from R&D is not a strong guarantee.

I also plan to connect both not because I like wasting my own programming time (as negligible as connecting an extra terminal might be) but because LV's behavior here is _inconsistent_ between versions and _silently_ changed. What guarantees do we have that it will not change again?

I think NI is quite a bit better these days at keeping behaviour consistent between versions, except when there is clearly "buggy" behaviour.

Given the focus on NXG I suspect it is pretty safe to say not too much is going to change in current gen LabVIEW going forwards.

[Michael Aivaliotis]

Automatic error handling is for noobs.

[hooovahh]

2 hours ago, Ernesto Aneiros said:

What guarantees do we have that it will not change again?

None.  There is no guarantee that the Add function doesn't start acting like the subtract if there is a full moon out.  It is just in NI's best interest to keep users of their software and hardware happy and that generally means consistent behavior, but bugs happen.

9 minutes ago, Michael Aivaliotis said:

Automatic error handling is for noobs.

I missed you Michael.