LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
SteenSchmidt

VIM and Inline debug with temporary instances

Status: New

The "Convert Instance VI to Standard VI" right-click option on malleable VIs made me think if this technology could be used for debugging otherwise inlined VIs (and therefore also malleable VIs)?

 

VIM Convert.png

 

VIs are obviously inlined without their block diagrams, so my suggestion would require two changes:

 

1) 'Allow debugging' must be settable in combination with inlining in VI Properties >> Execution.

2) LabVIEW IDE and RTE would have to call inlined VIs in different ways, depending on this setting. Suggestion follows:

 

Running in the IDE

The IDE would now create a temporary unique instance for each running inlined subVI that has debugging enabled. This would allow us to double-click on an "inlined" subVI while it's running, and have that temporary instance open up ready for probing. Settings like the 'SubVI Node Setup' dialog would now also be available for inlined VIs, if they have 'Allow debugging' on. Set 'Allow debugging' off and inlined VIs will behave as today (so no change for any existing code).

 

Running in the RTE

Executables are built with 'Enable debugging' either on or off (Advanced page of the Application Builder). I suggest that Application Builder builds in unique instances in place of debug-enabled inlined VIs when 'Enable debugging' is on, and bakes in ordinary inlined code when 'Enable debugging' is off. This would allow us to debug into inlined (and thus also malleable) VIs inside executables with remote debugging. Loose VIs called with the RTE would have had their inlined callees compiled with either debug capability or not, depending on their 'Allow debugging' setting as discussed above in "Running in the IDE".

 

What do you think - would it be nice to be able to debug inlined VIs?

CLA, CTA, CLED & LabVIEW Champion
11 Comments
AristosQueue (NI)
NI Employee (retired)

Inlining provides huge performance benefits, even in the IDE. If we changed inlining so that it doesn't provide those benefits, then, to me, that seems to be equivalent to turning off inlining. In other words, to me, an inline VI with debugging enabled is the same as a non-inline VI.

 

Given that, why not just make "is inlined" be a setting that can be toggled in AppBuilder? Currently, AppBuilder allows toggling of the Execution properties "Allow Debugging" and the "Enable automatic error handling". We could add "Inline subVI into caller" to that list. Now you could turn off inlining in the IDE and turn it on (or not) in the RTE. That seems like a better option to me than changing inlining in the IDE.

SteenSchmidt
Trusted Enthusiast
Inlining provides huge performance benefits, even in the IDE. If we changed inlining so that it doesn't provide those benefits, then, to me, that seems to be equivalent to turning off inlining. In other words, to me, an inline VI with debugging enabled is the same as a non-inline VI.

And that is how it would behave with debugging enabled: like a non-inlined VI*. It has the same benefits and drawbacks as being able to debug FPGA code. You can debug logic and data IO, but not gauge performance while doing it. Still a huge advantage compared to not being able to debug an FPGA VI.

 

*I will stress that debugging isn't allowed on inlined VIs today, so behavior for any current source will behave exactly like it does today, even with my suggestion. We would just add the option of enabling debug on any single inlined VI, and that VI would suddenly be probable (yes, with a performance hit, but nevertheless). Much simpler to temporarily enable debugging for a single VI in the IDE, than create a build spec with debug set for that VI, then building the executable, then connect to the exe with the remote debugger and so on.

 

Given that, why not just make "is inlined" be a setting that can be toggled in AppBuilder?

It's an enormous task to build an app, then debug that remotely, compared to just pop a probe into a subVI in the IDE.

 

I'm suggesting some means of being able to debug inlined VIs in the environments we already have. Sure there are drawbacks when debugging, for inlined stuff the drawbacks are a big performance penalty. This question would be moot if we had a global setting to control level of debug in the IDE, so we could gauge performance in one situation and probe deep into all code in another situation. I'm not keen on changing a large number of file properties to be able to debug, then remember where to change them all back again afterwards. There might be better suggestions on how to debug inline (and thus malleable) VIs, but bulding an application is way beyond the immediacy that LabVIEW offers in so many other situations.

CLA, CTA, CLED & LabVIEW Champion
AristosQueue (NI)
NI Employee (retired)

> It's an enormous task to build an app, then debug

> that remotely, compared to just pop a probe into a subVI in the IDE.

 

I think you missed my point. If you want to debug in the IDE, just turn off inlining. If you want inlining to be turned on when you build the app, then you would add that to your build settings. That seems much more sane to me than introducing a new "inlined but debuggable" setting that is identical to "not inlined".

SteenSchmidt
Trusted Enthusiast

How do I turn off inlining for malleable VIs?

 

The requirement to actually change source files to be able to debug some of them comes from the fact that debugging is a source file setting, not an IDE/AppBuilder setting.

CLA, CTA, CLED & LabVIEW Champion
AristosQueue (NI)
NI Employee (retired)

> How do I turn off inlining for malleable VIs?

 

You cannot. And it wouldn't help you if you could. Malleable VIs aren't debuggable for other reasons. I made them have the inline requirement because it solved a host of issues for them and was consistent with the rest of their behavior. That's a requirement I'd like to remove some day if I could work out the other problems so we can have malleable user interfaces. I made a stab at doing so in LV 2019, but it didn't work out.

SteenSchmidt
Trusted Enthusiast

Exactly, but malleable VIs would be debuggable with the feature I’m suggesting: that the IDE temporarily replaces that call site with a scripted scratch VI.

CLA, CTA, CLED & LabVIEW Champion
SteenSchmidt
Trusted Enthusiast

In other words, I can debug all of this by making small, sometimes quite big, changes to my source files. I’d just be happier if the IDE could automate these steps for me and throw away the changes afterwards.

CLA, CTA, CLED & LabVIEW Champion
AristosQueue (NI)
NI Employee (retired)

Steen: if inline VIs became debuggable without a substantial refactoring of malleable VIs, then I'd have to add another requirement to malleable VIs to prevent them from being debuggable. They have deeper issues than this.

SteenSchmidt
Trusted Enthusiast

I understand and accept fully your point Stephen, no problem.

 

To “debug” a malleable VI I could right-click on it and click ‘Convert Instance VI to Standard VI’, and then debug that instance. Afterwards I could replace the newly created instance with the original malleable VI again.

 

I merely suggest the IDE could automate those steps for me. Would that work?

CLA, CTA, CLED & LabVIEW Champion
AristosQueue (NI)
NI Employee (retired)

> I merely suggest the IDE could automate those steps for me. Would that work?

 

I think so. In my home time, I've been playing around with a right-click plug-in to do that, but I don't have it working. At work, I've been trying to figure out how to make that be more built-in.