07-20-2015 10:31 AM
Eldon: What you propose is an effective strategy for debugging many reentrant VIs. It should work here. Note that use of some asynchronous nodes may prevent you from inlining the subVI... in that case, just change the subVI to be pre-allocated reentrant. The "performance hit" from the subVI call is trivial (we're talking a couple microseconds on most machines) compared to the work being done by whatever asynch nodes prevented inlining from working.
07-20-2015 10:36 AM
This is exactly what I do also, Eldon, but I had never thought of putting it in-line as you suggest. Nice.
AQ, can you give an example of async nodes that prevent in-lining? I don't really ever use in-lining...
07-20-2015 11:25 AM
mtat76:
LabVIEW help: \lvconcepts.chm::/VI_Execution_Speed.html#SubVI_Overhead
or search for topic "VI Execution Speed" and the subsection about inlining.
It's a long list of characteristics, but it all comes down to "the stuff that changes behavior when you do 'create subVI from selection' cannot be in an inline subVI".