Conditionally include Front Panel of a Subvi in an EXE

[cober]

I want to make two versions of an EXE, one "normal" version and a debug version. I know how to set conditional disable symbols via pre/post build actions (btw. NI: these variables should REALLY be defineable per build specification; even bare command line C compilers are easier to use in that regard than Labview).

The "normal" version won't show anything but the main vi. The front panels shouldn't even be included in the exe. For the debug version I want to show the front panels on request (I've queues for sending that to the subvis). Simply calling "FP.open" does not work with an compiled exe, because I get a "resource not found" error (the front panel of the subvi is not compiled into the exe). I tried setting show "frontpanel when called" which forces the FP to be compiled into the exe, but then the FP will shortly flash on the screen, even when the first command of the subvi is hiding the frontpanel.

How can I make a subvi depending on a conditional disable symbol include its front panel into the exe without forcing it to show its frontpanel at the same time?

[JÞB]

Create the debug build and the normal build.  install as appropriate.  with the right  Symbols and the right command line arguments.  Clear?

[tst]

There are a number of things which cause LV to keep a FP when building. These include things like open when called (which you understandably don't like), but also various things which statically require the front panel. Things like changing the scrollbar settings or creating a property node for a control on the FP. Personally, my preference is for the latter because you can document it better.

If you don't actually mind whether the FP is included, you can just do that and be done with it. If you really do mind, you can check whether placing the property node for the control in a conditional disable structure has an impact on this or not. I have no idea whether it does or not, since I don't know exactly how LV will treat the code in the disabled case.

The other alternative is making two builds and configuring it for each VI:

The disadvantage here is that you have to manage two builds and do this manually for each VI.

If you want, there's a related idea on the idea exchange, but it won't actually help in your case, because it's not conditional:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-property-to-guarantee-that-the-front-panel-of-a-...

[cober]

Thanks, I tried this. The result: any property node of a FP object includes the frontpanel in the exe, even if the node is just within the disabled case of a disable structure (doesn't matter if it's a diagram disable or conditional disable structure). So these structures feel even weirder now for me. I thought of them like C-preprocessor directives like "#ifdef", which cuts parts out of the source as if it weren't even there. Are the disable structures then any different than a case structure with a constant (or global) wired to it at all?

So the only way really is to manually manage multiple builds, which is quite annoying, since some of the VIs I want the debug option for are used in multiple projects. And the only way you realize a front panel is missing, because you forgot to add it to the build specification, is when you try to show it. I'm tempted to use your trick with the property node to at least have the frontpanel included without being able to "forget" to set an option. But I hate it when Labview forces me to throw out clean programming or build workarounds or make something that's inefficient (at least it feels like that).

What are the drawbacks of having a frontpanel included even if you never show it? The debug frontpanels would contain all sorts of different indicators, from simple numerics to arrays of clusters and graphs. For some of them I can disable writing to via conditional disable structures, because they are purely for debugging. But many of them will be the input/output terminals of the subvi which obviously have to be written to.

[JÞB]

A front panel that is included but never shown simply increases the size of the execuable source.  Run time perfomance and memory usage should not be impacted.  FP object are not updated if the FP is closed unless you use a property or method that loads the FP  e.g. InsertBlockDiagram method:

Which makes me wonder if that help file isn't just a bit backwards in 2013  Insert VI method loads the BD but not the FP and InsertBD method loads the FP but not the BD?????  Hows that again?

[cober]

To test the performance impact I wrote several subvis that all (with one exception) write alternating 0 and 1 (10^8 iterations) to a chart. The subvis return the time it took. The results are quite annoying.

As I wrote before, a property node in the disabled frame of a diagram disable structure will still force the FP to be included, even if it will never be shown. This has some very bad performance consequences. Here are the times for the different subvis (all are doing a "for loop counter modulo 2" the result of which is written to a chart) after building an exe:

"standard" (not settings changed from default; front panel won't appear):

0.65s

like "standard", but "remove front panel" deselected in build specification:

0.65s

subvi set to "show when called":

17.24s

like "standard", but property node ("visible" property, set to read not connected to anything) placed on block diagram:

13.95s !!

like the one before, but writing to the graph is placed within an disabled diagram structure:

0.69s

like "standard", but graph has been deleted completely (modulo operation still done):

0.48s

So placing a property node has a major performance impact, even if you never ever see the front panel. Placing it in a diagram disable structure is no different than placing it anywhere else on the block diagram (talking about compilation/runtime effects). In the end to prevent the performance impact it comes to litter the block diagram with conditional disable structures around every indicator, which may not be possible for all of them, because they're not "just" debug.

[Hooovahh]

Would you mind posting your VIs you used for testing.  There are several tricks to help get consistent performance from timing tests and not doing this can give in consistent results.

EDIT:  Now that I re-read you post that does sound interesting, and I can see why that might happen.