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]

On a slight side-note I was pondering the following....

Why would one purposely place a control or indicator in a Conditional Disable structure and still expect VI Server or local variables to work?  Why would that be a desired use-case instead of simply being the way it works.  What I'm getting at is how many of these cases are like that simply because people did it that way and it worked and how many are like that because people thought "Hmm, this is what I want to achieve and that can only be done by placing the control in a conditional disable structure"?

I have trouble imagining any kind of reasonable response to the second part, which of course doesn't mean it doesn't exist but still.....

So what I'm getting at is that the inability to determine that the control is really being unused (and thus invalidate all property nodes, References and locals for that control) seems to be the barrier here.  I would reverse the chain of thought posted by Aristos "but it is a hole in our ability to prove the control is unused" to not imply that the conditional disable structure must be convinced that the control is unused elsewhere but rather for the conditional disable structure to be able to declare unequivocally that the control does not exist, re-aligning the planets.

[AristosQueue (NI)]

The thought when we designed it was that a conditional disable structure should shut down that part of the diagram, not any other part. There are plenty of places where I might have an FPTerminal inside a structure and an Event Structure watching that located somewhere else. The disable might even be within the frame of the event structure that is handling the event!

[dfjuggler]

I've read through the comments and I guess the details are currently beyond my understanding. Nevertheless, as a user I would expect and appreciate the fact that I could *completely* get rid of controls and indicators using the conditional and diagram disable structures, specially on the FPGA!

In the case where a user is still wanting to reference the object from another part of the application, couldn't he/she just make sure to leave that object *outside* of the disable structure?

I'm surprised that this idea is two years old and has gathered so little traction. Are people handling this inconvenience in a way I'm missing?

[AristosQueue (NI)]

> Are people handling this inconvenience in a way I'm missing?

Maybe. I can't ever be sure why something *isn't* a problem. 🙂 It could just be that very few people write VIs that they ever expect to be used on more than one target. They are rather specialized environments.

So, let's ask the question another way. What is your use case for needing this? In the image you posted, there's no reason to comment out the FP terminal... if you don't use wire it, the compiler will deadcode eliminate that unused output when building the VHDL. I think that a wide swath of cases where this is a concern are just handled by the compiler and so cease to be a concern. If you've got an actual scenario that you can lay out where you truly do need this commenting trick to work, maybe we can answer how other people are handling it, if they are.

[dfjuggler]

I did some experimenting and found these results:

Shouldn't A and C create very similar bitfiles? D and C are very similar and both are smaller than B. This makes sense since I guess the compiler is probably getting rid of some logic - the one generated due to the inclusion (B) or exclusion (C and D) of the wires. Still, I think it would also make sense get rid of the controls or indicators that are inside the CDS.

USE CASE #1: Debugging as when using the FPGA Desktop Execution Node (FPGA_EMULATION==TRUE).

USE CASE #2: Inclusion/exclusion of functionality. With the current behaviour one has to move from A to C through code editing. It would be nice to have (1) B resemble A when FPGA_ENHANCED==TRUE; and (2) B resemble C when FPGA_ENHANCED==FALSE. I haven't tried (1), but I guess that would be the case with the current behaviour since the compiler will probably get rid of the constant included in the disabled case.

Makes sense?

[AristosQueue (NI)]

I don't know enough about FPGA to comment on this. Your argument is persuasive. I'll pass this post along to the FPGA team and see if I can scare up some commentary.

[dfjuggler]

Thanks, I'll look forward to knowing if they like the idea.

I would comment that this behaviour would also make sense for Diagram Disable Structures.

[AristosQueue (NI)]

> I would comment that this behaviour would also make sense for Diagram Disable Structures.

Inside the C++ code, those two are essentially the same thing. One wouldn't change without the other changing.

[Dragis]

From the FPGAs perspective, the reasons for not removing the controls and indicators are precisely because the LabVIEW FPGA compiler matches the defined LabVIEW semantics. In LabVIEW, the front panel "data items" are not solely controlled by the diagram uses but also for "remote" access. Since there is no way to tell LabVIEW today when you don't want to provide remote access the compiler can't remove that functionality. I went in to more detail about the FPGA specific implementation back when this thread was originally started. The problem on FPGA is not quite as invasive as compiling for the Desktop since only the top-level controls and indicators are accessible off-chip.

There have been several long threads on this topics specifically for FPGA, unfortunately those threads are eluding my searching skills at the moment. In summary, if LabVIEW had a mechanism -- either from the VI, Build Specifications, or other configuration -- to disable remote access the optimizations mentioned here would be possible. I personally don't think the diagram disabling structures are the right way to do this since they are well defined only to turn off things encapsulated by the diagram. Something on the front panel item itself or in another configuration well like the connector pane editor seems more ideal. Having VI Server methods on the diagram to do it would be fine.

[Dragis]

Related: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-the-behaviour-of-Front-Panel-Controls-Indicator...