But what if you had a breakpoint set on the subVI. At the breakpoint, the panel is open, and you type in new data. Oops. The caller is supposed to protect the data, but if the terminal is conditionally read, it can't predict you won't do what I just described. On the otherhand, if the terminal is on the top level, the breakpoint on this VI will always happen after the data from the terminals is read. That means the subVI can truly be inplace only if its terminal is owned by the top diagram and not placed into a loop, sequence, or case diagram.
Although, since breakpoints are exposed in the VI server object hierarchy, it should be theoretically possible to only copy the data if a BP has been set, wouldn't it?
Or would that take up too much resources?
Or maybe there are other cases where you couldn't guarantee the inplaceness?
See what you get when you expose the decision making process? A lot of pests second-guessing your decisions...
BTW, I'm fairly sure that the part about placing the terminals in the root of the diagram has been documented in the style guide, so you should be alright there...
@greg McKaskle2 wrote:
That means the subVI can truly be inplace only if its terminal is owned by the top diagram and not placed into a loop, sequence, or case diagram.
Hi Greg eta al,
I think I got it!
The attached code an image illustrates what I concider a common construct that illustrates the point.
In the "good" version, the control and indicator are on the root of the diagram and LV can see that the array of the caller can be the same VI inside the sub-VI and the same with the returned data.
The "bad' version force a data copy.
On my laptop an array size of "1000000" and loop count of "1000" and error is "false"
Good = 1uSec
Bad = 23 mSec
With error = True
Good = 1uSec
Bad = 47 msec
Generally, the time required for "Bad" scales with array size (because of the copy) while "Good" is fixed up untill you run out of physical memory.
Message Edited by Ben on 06-25-2006 10:28 AM