Better handling of UI elements within conditional disable structures

[Intaris]

I use disable structures and conditional disable structures more and more as my coding starts to spread over multiple targets (Host, RT and FPGA).

I like to include some debugging indicators for my code so that I can (with the proper conditional disable symbols set) debug my code more easily but still remove the bloat for actual release code.

What I have noticed is that controls and indocators which are disabled int his way are NOT accurately represented on the FP.  As such I am surrently unable to determine by looking at the FP of a VI that perhaps half or all of the visible indicators are or are not actually being used in the code.

Even when the code is running, the controls and indicatory which are actually disabled are still visible (and supposedly still available over VI Server for example).  I think these controls should be actually removed or at least have a visual indication that they are diabled on the BD (distinct to the appearance caused by writing to the "Disabled" property of the control).

The LabVIEW help states: "When compiling, LabVIEW does not include any code in the inactive subdiagrams of the Conditional Disable structure" but I question how true this statement really is.

Although these controls are DISABLED (Not present in the source code)........

Here they are.....

This raises issues on the FPGA level more urgently than on the PC side, but I feel the sentiment behind the idea is the same.

Of course things get more compilcated when the controls are connected to the connector pane, but perhaps simply prohibiting the presence of a connector pane terminal in a conditional disable structure would solve that problem.

Shane

[Intaris]

Regarding the FPGA issue I have another IDEA on the same vein HERE.  The idea is badly named, granted.

Example: If I have debug indicators on my FPGA FP which I "remove" using a conditional disable structure, are they really removed before compiling or do they still gobble up resources but don't actually do anything?

[AristosQueue (NI)]

The FP terminal being inside a diag disable structure is not enough for LV to know that the control is not used. You may be opening a control reference to that terminal somewhere. Yes, we know it's a rare use case, but it is a hole in our ability to prove the control is unused. For that reason, we do not do anything to the front panel merely because the terminal for that control is disabled.

Various members of R&D are open to the argument that it is such an edge case that we should go ahead and remove controls from the panel if they are unused within the VI -- ie., not only is the terminal disabled, but there are no non-disabled uses (used on conpane, local variables, static-linked control references, etc). The idea that was put forth was that if the terminal was disabled and no other local references were found, we would hide the control (equivalent to popping up on the FPTerminal and choosing "Hide Control") when the VI started running and show it again when the VI stopped running.

These hidden controls would still "gobble up resources" -- although the use of the term "gobble" is odd in this instance since most controls are pretty small memory impact unless you stick a very large piece of data into them (either their current value or their default value). Removing them entirely (i.e., not returning them in lists of "all controls on the front panel") might be something we would do as part of Build Application, but not in the IDE.

The biggest question is what to do with Typedefs, XControls and classes. Does a hidden control still link to the typedefs? Do XControls count as "always included" since there's no way for us to know whether they have functionality that they run independent of their code? (I've seen XControls that you drop on a panel and they redo the layout of other controls in their run/stop run methods.) Similarly, does a class load its class? Keeping a class as part of a VI is sometimes a big deal since the objects of the class may only come into being through an Unflatten From String, so even if a control looks totally unused, the fact that it links at all can be important.

Answers to these questions would be useful for deciding what, if anything, to change about the behavior of control on the panel when their terminals are disabled.

(Note that I realize that the solution I describe above would not fix the "double type attempting to deploy to FPGA" problem. I *think* that's an orthogonal problem from the point of view of deployment.)

[Dragis]

Aristos covers all the fundamental problems very well. Namely, there is (at least currently) a distinction between the front panel item and the diagram accessors that item. The block diagram accessors are only one of the many ways one could interact with that front panel item.

Specifically speaking about LabVIEW FPGA, the situation is not quite as bleak since (at least currently) only front panel controls and indicators on the top-level VI are exposed to the user via the FPGA Interface from the host (analogous to the VI server control/indicator functionality). Even if the item is conditionally disabled on the FPGA side, the user could still read and write values to the register from the host side. And, yes, people have done this in some cases for debugging purposes of various sorts.

However, for VI calls within the FPGA, the compiler can and generally does remove any control and indicator "memory" that is unused by anyone. So if you conditionally disable all accesses to a control or indicator in a called VI the compiler will remove that code. In theory, this would allow us to handle the case of a disabled double control used for debugging a called VI. Since reporting the errors from the FPGA compiler take some time, the decision has remained that we will break unsupported types at edit time for faster feedback. That is a decision that could be changed given enough support.

[AristosQueue (NI)]

> In theory, this would allow us to handle the case of

> a disabled double control used for debugging a called VI.

In practice it doesn't since we error check VIs individually for a target as we have no idea which VI is the top-level VI until you actually attempt to deploy. Every VI on a target is checked on the assumption that it could be the top-level VI. That means that there's more hinting needed to know that we can skip the "is appropriate for target?" check on a given control.

This is something that is potentially changeable... I'm just laying out the situation currently.

[Intaris]

Gentlemen, I prefer simplicity in all forms, myself included....

I would have made the automatic connection with "How it should be handled" to be akin to "what happens when I delete the control in question".  It disappears, locals get invalid, references get invalid and so on.  The control is in Limbo.

It might require an extra step between what the user sees and the actual compiler where these controls are removed (or set internally to VOID) and the compiler gives feedback and the error list gets populated.

Most likely very simplistic, but I see no other way around it at the moment.

My FPGA code which I compiled today "without" my FP controls still ahve the FP controls available in the Bitfile definition. -sigh-  How do I go about including my debugging code now since it's exactly the presence of the FP items I need for debugging and really DON'T want when compiling "for real".

[AristosQueue (NI)]

> How do I go about including my debugging code now since it's

> exactly the presence of the FP items I need for debugging and

> really DON'T want when compiling "for real".

Maybe you could open a queue and instead of writing to a local control/indicator, you send them off to some other display? No idea how viable that is. Probably not very.

You could create a subVI that has the debug displays on it and then call to that subVI... when the subVI is in a diagram disable structure, it vanishes entirely. Thus there's no FP terms on the VI that you're deploying.

Those are the only two ideas that come to mind in today's LV.

[Intaris]

Shame really because the controls in a Conditional disable structure would be a really elegant and accessible method....

[Dragis]

"In practice it doesn't since we error check VIs individually for a target as we have no idea which VI is the top-level VI ..." - Aristos

Sorry for the confusion. What I meant was that we could support it if we allowed the feature in the editor (e.g. didn't break the VI when using a double type on the FPGA) but instead gave an error later during compilation when we do know what the top-level VI is. And like you said, there are many other ways to accomplish this as well.

[AristosQueue (NI)]

> Shame really because the controls in a Conditional disable

> structure would be a really elegant and accessible method....

No disagreement there. That's why I'm posting all these questions, so you know why it works the way it does currently and can evaluate how each of these edge cases should be modified in the future.

[Dragis]

I have started passing a Debug class through hierarchies I construct for exactly these types of scenarios. The interface has ways of logging messages, warnings, and errors which I call from inside conditional disable symbols. From the top-level I can pass in a Noop implementation for the FPGA side (or a very simple implementation that logs to a trace buffer). The desktop implementation writes to a more complicated front panel view.