LabVIEW
Inline Method Hangs
Solved!
In my test cases, 
In my use case, "Inline" is being called by a sub VI (Flatten VI for Package.vi) that is being called by a post-build action VI (PopUp POST-Build Action.vi).
I thought it might have something to do with the context in which it is running; which is "NI.LV.MxLvProvider". Normally, I can call a VI in an alternate context by doing this:
But strangely, when I try running that code from "NI.LV.MxLvProvider" the sub VI that's called by reference is still in "NI.LV.MxLvProvider", and not in "GUEST" context.
Any clues would be appreciated.
As I understood, you are taking a VI and trying to replace all its subVIs by their content, iteratively until you reach NI VIs only.
1. On the following assumption:
@paul_cardinale wrote:when I try running that code from "NI.LV.MxLvProvider" the sub VI that's called by reference is still in "NI.LV.MxLvProvider", and not in "GUEST" context.
Dumb question: Are you sure you wired properly the application refnum to the property node ? Here it appears you display the ContextName of the owning app, not the "guest" app:
2. About the "Inline" method hanging:
a. Is it hanging from the start, or after several "Inline" operations ? After how many "Inline" operations ?
b. Can you identify (by logging VI names) which specific VI or which type of VI is causing this hanging ?
c. What is the expected complexity of the final VI ? I mean, depending on the number of subVIs in the call hierarchy, replacing everything iteratively by its content could give quite a massive block diagram. Maybe LabVIEW cannot handle so many nodes in a single diagram !
3. For my own curiosity:
a. Is there any reason for doing this in a separate ("guest") application ?
b. Is there any reason why you don't simply use the "Inline" checkbox of the VIs instead of actually replacing by their content ?
Regards,
Raphaël.
@raphschru wrote:
As I understood, you are taking a VI and trying to replace all its subVIs by their content, iteratively until you reach NI VIs only.
1. On the following assumption:
@paul_cardinale wrote:when I try running that code from "NI.LV.MxLvProvider" the sub VI that's called by reference is still in "NI.LV.MxLvProvider", and not in "GUEST" context.
Dumb question: Are you sure you wired properly the application refnum to the property node ? Here it appears you display the ContextName of the owning app, not the "guest" app:
Yes. The purpose of that was for me to verify what context "Flatten VI for Package.vi" is running in. The "Context.Create ..." method within "Flatten VI for Package.vi" is probably superfluous.
2. About the "Inline" method hanging:
a. Is it hanging from the start, or after several "Inline" operations ? After how many "Inline" operations ?
b. Can you identify (by logging VI names) which specific VI or which type of VI is causing this hanging ?
c. What is the expected complexity of the final VI ? I mean, depending on the number of subVIs in the call hierarchy, replacing everything iteratively by its content could give quite a massive block diagram. Maybe LabVIEW cannot handle so many nodes in a single diagram !
It always hangs on the first call.
3. For my own curiosity:
a. Is there any reason for doing this in a separate ("guest") application ?
b. Is there any reason why you don't simply use the "Inline" checkbox of the VIs instead of actually replacing by their content ?
Regards,
Raphaël.
The reason for using a guest app context was just an attempt to get it not to hang.
I don't see an "Inline" checkbox anywhere. Where is it?
@paul_cardinale wrote:I don't see an "Inline" checkbox anywhere. Where is it?
This one:
Or VI property Execution:Inline SubVI
As explained here (section DFIR decomposition), inlining a SubVI is equivalent to replacing by its content, wrapped in a FlatSequence, in the caller VI. So I don't see any advantage in replacing by the content explicitly.
@raphschru wrote:
@paul_cardinale wrote:I don't see an "Inline" checkbox anywhere. Where is it?
This one:
Or VI property Execution:Inline SubVI
As explained here (section DFIR decomposition), inlining a SubVI is equivalent to replacing by its content, wrapped in a FlatSequence, in the caller VI. So I don't see any advantage in replacing by the content explicitly.
Hmmm. Interesting possibility. But it would require that I manually recurse through the sub VIs and change their properties.
@paul_a_cardinale wrote:Hmmm. Interesting possibility. But it would require that I manually recurse through the sub VIs and change their properties.
...in the same way you wanted to recursively replace subVIs with their content.
But there is a more difficult question to solve: Since inlining implicitly requires VIs to have preallocated clones, how are you going to decide whether to inline or not to inline (that is the question) ?
For example, a non-reentrant stateful VI (like an FGV) should not be inlined. Also, overusing inlining can lead to big memory use and an increased allocation time when creating a clone of the top-level VI, see here for a related thread. More generally, execution properties of each VI should have already been chosen carefully during development.
So deciding automatically whether it can be inlined would suppose to create a script that is "smarter" than the developer who created the VIs in the first place… You would have to make deductions based on the VI properties, detect statefulness by parsing its diagram, maybe even script and run benchmarks to choose the best memory usage vs speed tradeoffs when you inline or not a subVI (or by using diagram complexity statistics)… seems very hard !
