Add an error handling element to inplace node.

[Matt_W1]

I've been messing around with DVR LVOOP and have found that the inplace node makes proper error handling a bit tedious. First I need to handle errors passed into the vi, Then I need to handle multiple errors from the read elements then the write elements.

For example if I have two DVR LVOOP Items and I want to move a string from one and concat it onto the string in another I need to do this (see initial.png attachement)

I propose the following (might benefit from some more graphical tweaks), which is functional equal to the above (see improved.png attachment).

Note: No data is modified if an error is passed into the inplace node or if any readers produce an error. Any warnings passed in are maintained. If multiple errors are produced from the readers or writers the highest on the inplace node is the one reported. This would also work with errors from the Variant to/from elements (and variant attributes if those ever get added to the inplace node).

[Matt_W1]

I was hoping that I could edit the message to embed the attachments (how the old forum used to work when I was more active).But it seems that work around is no longer needed. But I can't figure out how to edit my post. So any moderators please feel free to fix it and remove this post.

So here's the files proper embedded.

[AristosQueue (NI)]

Both of the "error out" terminals produce EXACTLY THE SAME ERROR. There is no need to do a Merge Error call at that point.

Having said that... I like your idea in general... but I would not give it an error in. That creates problems... there's a reason it does not exist on the current IP Elt node. But kudos for the consolidated error output.

[Matt_W1]

Didn't know the errors were duplicated on the error outs (not seeing it mentioned in the LV2009 Help file).

The only problems I can think of with the error in are that

1. It would be hard to implement (I'm not privy to NI's compiler implementation but it seems like a transformation on the DFIR would be pretty straight forward).

2. Messes with the inplaceness algorithm somehow (If the the inplaceness algo happens after the above DFIR transform it should be equal to the Initial form).

3. Adding an error modify set's a precedence for error in's on other structures. Like people wanting an error in on there for loops. This get's rid of two error merges and two case structures (not just one structure). And of course there's the timed loop....

4. It masks which set of read elements failed. This is apparently already an issue with the write side. But the read errors could be routed to the error outs of their respective writes (If someone wants to check on what failed).

6. I'm not handling errors properly in the initial version.

5. Some quirky thing in I'm unaware of (lack of knowledge,isn't public, or a planned future feature).

[Matt_W1]

Oh just checked, you meant that the reader element spits out the same error as the writer node. I thought you meant that the writers and the and readers both merged their output. That fixes problem 4. And as far as I'm aware the write elements can't fail separately from the read elements, so I guess that saves one merge.

[AristosQueue (NI)]

Yes, that's what I meant.

And I definitely like the idea because it fixes the other merge problem. BUT, I've since been informed of a problem that this would create -- how would a person handle each error separately? Because, you know, some people actually handle errors apparently -- I just kill the whole program when the first error occurs, but I'm not usually in charge of life/death systems. 🙂

*sigh*

[Matt_W1]

Read the errors out of the write elements or don't add the error in/out element and use the current system.

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.