Can we have an error in terminal on the in place element?

[DeltaJ]

Whenever I use a DVR with the inplace element structure - particularly if I unwrap data which is then actioned by a subVI or function which has error terminals - I have to use a merge error function to make sure any errors reach the error handler. Could we have error in terminals on these functions - in the image below I'd like the two pieces of code to have similar functionality!

This is also the case with the variant in/out border node. In that case both sides of the node have error outs while in regular code the convert to variant has no error terminals and the convert from variant has an input and an output!

My preference would be that the border functions would be exposed to errors on the error wires. However maybe there is a good reason this feature is missing due to the inplace functionality. If so perhaps we could get an implementation that is cosmetically identical to the lower drawing but programatically identical to the upper implementation (aside from the bounding case structure). Essentially the border nodes would all include a 'merge error function' instead of being exposed to the error input outright.

Thanks,

DeltaJ

[fabric]

There are many times when I've also thought error in connectors would be useful on IPE nodes... It has been suggested here as a small (maybe overlooked?) part of a rejected IPE idea. May have been suggested elsewhere too.

Anyway - kudos from me 🙂

[DJed]

We considered this behavior when the nodes were created. The problem is that taking an error on the DVR read/lock is very ambiguous. Sure it could take the error in and merge it with any errors it creates, but the behavior of the node is such that it would ignore any error and still operate as normal. Plus if you have multiple ones, how should this merge errors take place? Likewise, on the DVR write/unlock, you've operated on the data in place, wiring up an error cannot undo your operations, the node's behavior again would be as usual regardless of the error. Also, just FYI, the errors of the two bordernodes are the same result; the only errors generated are by the read, but we duplicate the error for you on teh read and the write so you don't have to wire through the structure; there's no need to merge both of them as you did.

The proper behavior if you want to use the error in the structure, is to wire the error into the structure and merge it with the DVR read. Then there's no need to merge again with the write.

Currently, this is intended behavior.

[DJed]

Oh and yes, this idea is a duplicate.

[DeltaJ]

Good spot fabric on seeing the other idea - I guess it was overlooked when the idea was declined - and i missed it myself when I searched to see if this idea had already been put forward!

Fingers crossed this idea (MikaelH's originally and which he tried to keep alive when his whole suggestion was declined) can be considered on its own merits!

[DeltaJ]

Thank you DJed for the information regardin the two outputs being identical - applying that will make my code a little cleaner in the future!! 

[AristosQueue (NI)]

Another, slightly easier to read, solution is to put a case structure around your Inplace Element Structure and have the case structure skip the IPE entirely if there's an upstream error. This works for me in 90% of cases and, because it is a less unusual error handling strategy, seems to give other people an easier time reading my code.

[fabric]

@DJed:

+1 for the nugget that the error on the read and write are the same! That will save some wires 

[James_McN]

---

@DJed wrote:

just FYI, the errors of the two bordernodes are the same result; the only errors generated are by the read, but we duplicate the error for you on teh read and the write so you don't have to wire through the structure; there's no need to merge both of them as you did.

---

I have also been doing this consistently. This seems to go against what I would consider standard error style in LabVIEW. I would expect the read to throw the error and then you wire it through your VIs. You don't want them to execute on rubbish data anyway and then it comes out of the end. Bypassing this seems counter intuitive.

That said, now its their I guess its difficult to remove without breaking a lot of peoples code.

[James_McN]

So I was going to just ignore the second error thinking that I can save my node count in my code now I know this but then the thought occurs to me that what happens if I do this and the functionality changes in the future so write can produce an error.

Therefore I really believe that each should have an error in/error out pair to keep to LabVIEW conventions and make the node easier to use. If there is an error on the input there seems to be two options:

• Access the DVR anyway and pass the original error. This will still block other code but keeps to the idea that in an IPE we have access.
• Don't access the DVR and pass the error. The internal code shouldn't try to do anything in an error condition.

I think the first is better and acceptable as long as it is documented.

[Darren]

Duplicate of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/DVR-and-IPE-Structure-Feature/idi-p/1528574