DVR and Error handling

[eberaud]

I have some old VIs to which I need to give some love. All the error clusters were unwired, so I am working on that... 

I am wondering what would be the best practice when it comes to DVR. The IPE structure gives an error cluster on both the left and the right data node. The attached picture shows all the error handling I can think of, but I wonder if it's not an overkill. Here is the breakdown:

1) Outer case structure: If there is an error before going inside the IPE, it just skips the IPE altogether and propagate the error cluster.

2) IPE left data node: I don't need to merge it with any incoming cluster since we are in the "no error" case (what about warning? am I speaking too quickly?).

3) Inner case structure: as long as the code inside it knows how to deal with the error (likely skipping its own code and propagating the error), I probably don't need this structure. What do you think?

4) IPE right data node: in what scenario would it actually give en error? If the DVR is bad, the left data node will take care of generating the error... Is it there is case the DVR becomes bad during the IPE execution? If I wire the right data node, then I need to merge it with the error cluster coming from the code inside the IPE...

Any comment more than welcome!

[infinitenothing]

The secret is that the incoming error is always the same as the outgoing error. Grab it where it's more convenient but you don't need both. If you need the warning, and I never do, you can merge it at the top on your rightmost merge.

Reference: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Can-we-have-an-error-in-terminal-on-the-in-place-element/idi-p/2008551

Edited July 7, 2016 by infinitenothing

[smithd]

I typically take the left node error, merge with error in, then inside the IPE structure I'll either wire that merged result into the VI or into a case structure as you have it. I ignore the output error.

I also don't put so many error structures as you have (for the same reasons as #1 here: https://decibel.ni.com/content/docs/DOC-47123). Obviously this is case by case, which is harder to manage if you're going through an entire project retroactively.

What does the mark as modifier do for DVRs?

[eberaud]

8 hours ago, smithd said:

What does the mark as modifier do for DVRs?

Good question, I never really understood that option.

[smithd]

http://zone.ni.com/reference/en-XX/help/371361H-01/glang/in_place_element_structure/

If I remember what aristos told me about the lvoop comment, the mark as modifier would really only do anything for dynamic dispatch. He said something about how if the parent class just passes the data through without modification but you know most children will modify the data, this cues the compiler to know hey, you're going to need a copy of this data you can't pretend this section of code is read-only. With a DVR, you always lock the value and I would assume operate in place, so I can't imagine why this would do anything for DVRs.

Edit: lol

Also on the original DVR subject, aristos' comments here may also help: 
https://decibel.ni.com/content/docs/DOC-40468

Edited July 8, 2016 by smithd

[eberaud]

Thanks. So we are talking about when you have a Dynamic Dispatch method inside the IPE, and not the other way around, right?

[ned]

No, the other way around. Let's say you have some data that passes through a dynamic dispatch VI (that is, there is an input and a corresponding output of the same type). The parent method passes the data through unchanged, so LabVIEW expects that it can reuse the input buffer for the output buffer. Now you override that method in a child, and you do modify the data. At compile time, LabVIEW uses the parent class (it can't know about all the possible child overrides) to determine whether it can expect to reuse the buffer. At runtime, when the child class runs, LabVIEW discovers that it needs to create a copy (to accommodate the modified data) and so it needs to allocate an additional buffer.

Now, if instead you put an in-place element structure in the parent, and marked the terminal as a modifier, at compile time LabVIEW will pre-allocate a buffer for the output, even though it's not necessary in the parent, which will allow the child that modifies the data to execute a tiny bit faster.

I'm not sure why this would ever be a useful option for a DVR.

[eberaud]

Oh so it has nothing to do with the DVR node of the IPE? So you're talking about putting an IPE with the simple In Place In/Out node?

Edited July 8, 2016 by Manudelavega
Added screenshot

[smithd]

Yeah thats right, that option is available on all ipe nodes but it sounds like its only a good idea to use it in exactly one situation, so the usage you showed above is probably not a good idea.

[eberaud]

I see, ok thank you both, that was really helpful!