inline subVI probe

[JesseU]

Using inline subVIs allowed a very time critical waveform generating VI to be much more readable with subVIs yet without unacceptable performance loss .  It's a shame NI has not figured out a way to still allow a probe to be used in an opened inlined subVI during execution of the calling VI.  To me it seems there must be some way to do this, since an inlined subVI just becomes essentially a portion of the calling VI code during execution.   

[AristosQueue (NI)]

The major problem is that we do not inline the block diagram. We inline the meta-assembly code that the block diagram generates (it isn't actually assembly code yet, but it is no longer G). That saves a lot of time during recompiles instead of scripting G code into the actuall caller diagram. Thus, there aren't any wires for a probe to be dropped onto in an inlined subVI. We've talked about ways around this, but haven't hit on any good ideas.

I'll give this idea Kudos because it is something we need to keep thinking about.

[JesseU]

Ah I see.  Just a thought, but what about for any subVIs that are open during execution of the calling VI, the G codes for those opened subVIs are instead scripted into the calling diagram during execution so that they can be probed? Once one of those opened subVIs is closed (i.e. front panel/block diagram not open), then upon the next execution of calling VI, that closed subVI would no longer be G scripted, rather being inlined the usual way with meta-assembly code. 

[JesseU]

When I said next execution of calling VI, I meant when the main VI is stopped and then ran again, as to when the mentioned subVI would change the way its compiled.

[AristosQueue (NI)]

If it needs recompile, that makes it tricky to remote debug the runtime engine. But viable idea otherwise, I think.

[SynchronizationOverhead]

I would also love for us to be able to debug into inlined subVI code. Visually, I think we could probably just treat the inlined subVI code the same way we treat reentrant subVIs, and let the user create probes and view execution highlighting/breakpoints in clones of the original inline subVI. Unfortunately, during the current process of inlining the subVI's DataFlow Intermediate Representation (DFIR) graph into each caller, we lose the mapping between the original (user-visible) source nodes and the DFIR nodes that will generate the executable code. Because of this architectural restriction, we chose to disallow debugging in inline subVIs for the initial release. We have been brainstorming ways that we could enable debugging in inline subVIs, but have not hit upon any easy answers. Thank you for your interest. Encourage others to upvote this idea, and we will continue to brainstorm.

Thanks! 

[JesseU]

You know for some reason I didn't think of it at the time but it's really fine to just switch out of inline mode during debugging, since for me during debugging I don't really care about delays, but rather just trying to get the program's logic correct.  Thanks for the detailed explanations. 

[Wolfskill]

If we can't have the ability to probe with inlined VIs, it would be really nice to just have a mode that you could globally set in the LabVIEW Environment for a debug mode that turned off inlining for everything (but didn't save them that way, just for when you are running them while that flag/mode is set). 

[AristosQueue (NI)]

Wolfskill: Can you post that as a new idea? That might get traction.

[Jared7]

Wolfskill, did you re-post your idea yet? If not I will. It's a simple way of turning on and off debugging for all VIs at once. This is similar to 'debug' and 'release' builds in Visual Studio projects.