LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

DVR and IPE Structure Feature

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


 

 

8 Comments
Member

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.

Member
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
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".

Proven Zealot

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). 

Active Participant
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.
Grant H.
National Instruments
LabVIEW Product Marketing Manager
Member
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.
Proven Zealot

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.

Member

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

Error Node.png