HiI 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.
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.
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".
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).
In another thread, Bakk_Diagram offered another variation. You can read the full suggestion here. One point I wish to clarify.
> 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.
I'm neutral on this idea but there is a precedent for an error in on a structure.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.