LabVIEW Idea Exchange

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

DVR and IPE Structure Feature

Status: Declined
Obtaining this functionality would be better achieved if two Data Value References (DVR). One would be for the original unmodified data value and the other would be the one operated on. Once all operations are done then you could use the Swap primitive inside of the In-Place Element structure to update the unmodified DVR with the operated DVR.

Hi
I don't think this is a new request but I could find it in the exchange.
I like to make the DVR-IPE structure more user friendly.
The image should explain everything.

Cheers,
Mike


 

 

12 Comments
S_Kamath
NI Employee (retired)

What is your use case for the unsafe copy of DVR contents? That seems like it would only cause problems. If the DVR is locked somewhere else the copied data is in an undefined state and no good can come of using the data.

MikaelH
Active Participant
I normally have references to instruments as well as "normal" data that can change from time to time. I would like to be able to get these instrument references to access them even if someone is modifing "normal data". If someone is locking up data for a long time, and I only wants to read more static data I don't want to be locked out. Cheers, Mike
Lefi
Member

I like the idea of copy data and time out!

But I think that the error wire should be reserved for errors. The sequencing can be solved with dummy wires or "film frames".

AristosQueue (NI)
NI Employee (retired)

Major problem: You wouldn't get the value that was the value at the start of the lock. You would get whatever interim value is currently in the wires that are executing within the IPE. The whole point of the Inplace Element Structure is that no copy is made. That means that while the lock is acquired, the value in the DVR is being modified. An unsafe copy would give you the value that it is at that moment, not the unmodified value. That means you would often be dealing with a junk value if LV had decided to inplace things in some strange manner or was reusing the array buffer behind the scenes temporarily as it passed through the IPE. Fixing that would destroy the performance benefits of the DVR.

 

If you're concerned about this issue, use two DVRs, one that is the finalized value and one that is the modifiable value, and copy from one to the other whenever the modification is finished (actually, don't copy... open both DVRs using an IPE and use the Swap primitive). 

G-Money
NI Employee (retired)
Status changed to: Declined
Obtaining this functionality would be better achieved if two Data Value References (DVR). One would be for the original unmodified data value and the other would be the one operated on. Once all operations are done then you could use the Swap primitive inside of the In-Place Element structure to update the unmodified DVR with the operated DVR.
MikaelH
Active Participant
I know that getting a Copy of a DVR data that is currently under modification might be a bit too much to ask from you, but the Error in and out from the IPE node is something that would make the data flow much cleaner, please think about this.
AristosQueue (NI)
NI Employee (retired)

In another thread, Bakk_Diagram offered another variation. You can read the full suggestion here. One point I wish to clarify.

Bakk_Diagram wrote:

> If the DVR is Bad the IPE doesn't execute.

 

That is a meaningless statement. If a node in LV doesn't execute, then nothing downstream of it is going to execute. The node has to do *something*. You may intend to mean something like "if the DVR is Bad the IPE sets all of its output tunnels to the default value and carries all of its border node inputs across to outputs without being modified."

 

Sorry if this sounds pedantic... when discussing language features, it is important to be very very precise in the description of behaviors or else the conversation clearly becomes confused because different people interpret ambiguous statements in different ways.

Oligarlicky
Member

 I'm neutral on this idea but there is a precedent for an error in on a structure.

Error Node.png

 

joshua.l.guthrie2.civ
Member

Error handling in the in-place DVR is a mess.  Holy rats nest Batman.  Cleaning it up like shown in the pic would be a great help.  Not sure I like the idea of copying DVRs.. But the timeout option, holy crap that would be helpful!  Having a lock completely freeze your program w/o the ability to throw an error is entirely unsat!

 

If we could just clean up error handling, that would be a huge start.

 

<side rant>
I always laugh when I read https://www.ni.com/en/support/documentation/supplemental/06/labview-object-oriented-programming--the... 

 

To me, it reads more like an apology than an explanation.  I have no idea why the militant insistence on "by value" NI has with LabVIEW.  A lot of the benefits of OOP is dealing with large data sets, which lend themselves to by-reference.  Besides, NI uses by reference in their OOP implementations, so why not let us.  Look at the invoke nodes for things like controls.  They are just methods being handled by reference... and shoot, they even have inheritance.  Why not give us the same capabilities!

</side rant>

wiebe@CARYA
Knight of NI

> I have no idea why the militant insistence on "by value" NI has with LabVIEW. 

 

Because "by value" works well, and avoids a lot of problems.

 

For example, you cannot create a race condition with "by value" code.

 

Problems start when you (have to) switch to "by reference" or "global" or "named global".

 

This goes for any programming language, not just in LabVIEW...