Conditional Disable based on build/development

[turbophil]

I am trying to cut down on memory usage in my RT application, and one of the methods I am exploring is replacing some of the larger subVIs with VI Server Call by Reference nodes. My problem is, I want to be able to debug the VIs in question when running in development mode, so I'd like to be able to switch between calling by reference (when compiled as an executable) and including as a subVI (when running in development mode).

I know I could use conditional disable structures to select the calling method, but that would require me to change the conditional disable symbol(s) each time I want to build the executable or run in development mode. Is there any way to set a conditional disable symbol based on the application type, or set the symbol from within the build specification? Or is there another (better) way to do it besides conditional disable?

I realize I could just throw an App.Kind property node on the block diagram with a case structure containing the subvi for "development mode" and the Call by Reference node for "Run-Time Engine", but my understanding is that the subvi will still be loaded into memory when the calling VI is called (by virtue of placing it in the block diagram), even if that case is never executed. Please feel free to enlighten me if I am incorrect about this!

[jdunham]

QUOTE (turbophil @ Feb 18 2009, 10:06 AM)

I know I could use conditional disable structures to select the calling method, but that would require me to change the conditional disable symbol(s) each time I want to build the executable or run in development mode. Is there any way to set a conditional disable symbol based on the application type, or set the symbol from within the build specification? Or is there another (better) way to do it besides conditional disable?

I think you are on the right track; using CD is the way to go. Presumably you know you can have some symbols which are for the whole project, and other symbols that are per-target (it depends where you right-click). You may be able to do what you need by putting the symbol only in the RT target, so that whenever you run on the local machine, it will use a different conditional symbol case.

If you need more complex behavior than that, I wrote a VI to change the symbols programmatically, which may help you switch back and forth. I was going to put this in the LAVA code repository, but I can't deal with the bureaucracy today, so here it is, attached (labview 8.6.1). Hopefully later I can submit it the right way.

[ragglefrock]

QUOTE (turbophil @ Feb 18 2009, 12:06 PM)

I am trying to cut down on memory usage in my RT application, and one of the methods I am exploring is replacing some of the larger subVIs with VI Server Call by Reference nodes. My problem is, I want to be able to debug the VIs in question when running in development mode, so I'd like to be able to switch between calling by reference (when compiled as an executable) and including as a subVI (when running in development mode).

You can have the best of both worlds. Look into the Call Setup property for a subVI. Simply right click your subVI on the caller's block diagram and select Call Setup from the right click menu. From there you'll see a few options: Load with Callers, Reload for Each Call, and Load and Retain (or something like that). Reload for Each Call is basically equivalent to the Call by Reference you're trying to implement, but it's as easy to debug and deploy as a subVI. Try using this setting on both RT and Windows. Alternatively, you can use Load and Retain or whatever it's called, which means don't load the subVI until it's first called, but then keep it around in case you need to call it again.

Debugging is great. You can step into it, set breakpoints, access its front panel, block diagram just like a regular subVI. But deployment is very easy. It's seen as a dependency and automatically deployed to the target or included in a build with everything else. You don't need to add it as a dynamic VI in the App Builder.

[JustinThomas]

You could also use the App.Kind Property which outputs an enum. This can be wired to a regular CASE Structure.

App.Kind would give output as Development System when running in the LabVIEW IDE and Run Time Sytem when running as EXE.

[Rolf Kalbermatter]

QUOTE (JustinThomas @ Feb 18 2009, 11:38 PM)

You could also use the App.Kind Property which outputs an enum. This can be wired to a regular CASE Structure.

App.Kind would give output as Development System when running in the LabVIEW IDE and Run Time Sytem when running as EXE.

But since the VI is in a normal case structure it will be compiled into the executable. This is exactly what the OP wanted to avoid.

However I do not see the real problem. I'm frequently debugging (single stepping) into VIs called with Call by Reference and that seems to work fine. Of course both the caller and callee need to be on the local system then.

Rolf Kalbermatter

[LAVA 1.0 Content]

I was even able to debug a compiled executable. The new functions for this feature are great!

Ton

[Rolf Kalbermatter]

QUOTE (Ton @ Feb 19 2009, 03:39 AM)

I was even able to debug a compiled executable. The new functions for this feature are great!

Ton

And that even works remotely.

Maybe not a good idea to do that over internet with a 100 ton press controlled by LabVIEW or some heavy motion system but for some applications it can be really good.

Rolf Kalbermatter

[JustinThomas]

QUOTE (rolfk @ Feb 19 2009, 02:03 PM)

But since the VI is in a normal case structure it will be compiled into the executable. This is exactly what the OP wanted to avoid.

Rolf Kalbermatter

Yes that is right. I completely forgot about that situation. Thanks for correcting me

[benjaminhysell]

QUOTE (jdunham @ Feb 18 2009, 03:12 PM)

I think you are on the right track; using CD is the way to go. Presumably you know you can have some symbols which are for the whole project, and other symbols that are per-target (it depends where you right-click). You may be able to do what you need by putting the symbol only in the RT target, so that whenever you run on the local machine, it will use a different conditional symbol case.

If you need more complex behavior than that, I wrote a VI to change the symbols programmatically, which may help you switch back and forth. I was going to put this in the LAVA code repository, but I can't deal with the bureaucracy today, so here it is, attached (labview 8.6.1). Hopefully later I can submit it the right way.

This is a great little library, but one issue I'm having that I'm not sure if what I am seeing is the proper behavior.

I'm using conditional disables to do unit testing with...so in my unit test I will set a conditional disable then run the unit test.

Right now my project has one setting, SendEmail, and I am toggling it between true and false.

When I run my unit test, I use your vilib to set the SendEmail = true, however when I watch my vi as it runs the false conditional disable case runs on the first run through. If I run the unit test again this time the conditional disable will run the true case.

It appears that what ever the conditional disable symbol that is set to before I start a run is the one that is actually executed, however if you look at the block diagram this isn't the case. i.e. the conditional disable I want to run is actually 'enabled' yet doesn't run.

Thoughts?

-ben

[jdunham]

QUOTE (benjaminhysell @ Feb 26 2009, 01:55 PM)

This is a great little library,

Thanks! I'm glad it's getting used.

QUOTE (benjaminhysell @ Feb 26 2009, 01:55 PM)

... it runs the false conditional disable case runs on the first run through. If I run the unit test again this time the conditional disable will run the true case.

It appears that what ever the conditional disable symbol that is set to before I start a run is the one that is actually executed, however if you look at the block diagram this isn't the case. i.e. the conditional disable I want to run is actually 'enabled' yet doesn't run.

Well I think that makes sense. These symbols affect how your VI is compiled, but if your VI is part of a running hierarchy, it can't be recompiled. Once your VIs stop, the new symbol is imposed, and then you run again and see the results you expected. Basically you are going to have to impose all of your symbols before any execution of your unit tests, which may require some dynamic VI invocations.

[ThomasGutzler]

Time to wipe the dust off this one.

 

I found myself in a similar situation as the OP where I want to exclude code using Conditional Disable Structures.

In my project, I have multiple Build Specs and I wanted to change the Conditional Symbols based on which Build Spec I'm running. For example, I could have a Debug and Release Spec.

I know that the IfDef.llb (LV\resource\plugins\Utility\) provides a SetSymbols.vi, so my first thought was to have a Pre-Build Action which calls SetSymbols.vi to set my key-value pair. That works fine.

 

This could turn messy if there are multiple Symbols that might need setting for different Build Specs and instead of having lots of small vis that each set a single Symbol I want something a bit more manageable. So why not allow setting of the Symbols via the Build specification description?

 

So I made a small vi that you can drop in your Pre-Build Action.vi, which reads this text and sets any of the symbols it finds.

LcExtra_IfDefSetSymbols.viLcExtra_IfDefPreBuildDropIn.vi

People who don't like this idea may want to replace reading the Build specification description with reading a separate .txt file which they include in the project that contains symbols for all possible build specs. There are many ways ...

 

Of course, if you're in any way interested in this topic, the first thing you should do is support this idea in the LabVIEW Idea Exchange, which would make all of the above obsolete.

[hooovahh]

Very neat thanks for sharing.  I wasn't sure that this would work as a pre-build, because I know that setting the version of the build in a Pre-build VI doesn't work.  The version appears to be read when the build start (before pre-build) and then changing it in a pre-build VI just changes the version which will be used in the next build which isn't useful.  Good to know the conditionals don't work this way.

 

One thing I've wanted to do for a while now, but haven't had the ambition for, is to allow conditional items in a project to be toggled using a right click menu in the Project.  Imagine if I could right click my project in the project window, and in it is a sub item like Conditional Symbols >> and then under the Conditional Symbols is all of the conditional symbols that are True or False (or TRUE or FALSE, or 0 or 1) and the items are checked or not checked based on the current value and clicking the item will toggle it.

 

The good news is NI has provisions to augment the project explorer window, and this is theoretically possible using this.

 

https://lavag.org/topic/18545-i-have-taken-the-first-step-towards-unofficially-opening-up-the-project-provider-framework/

 

The bad news is lack of documentation makes it difficult.  I tried by taking an existing plugin and modifying it and I didn't get very far.  Even so I think this could be a good tool for quickly turning settings on and off with a simple right click.

[Mellroth]

The bad news is lack of documentation makes it difficult.  I tried by taking an existing plugin and modifying it and I didn't get very far.  Even so I think this could be a good tool for quickly turning settings on and off with a simple right click.

 

The documentation is only bad if you don't go to the original source...

 

Right clicking to toggle Conditional Symbols would be very nice indeed, but I think one problem would be that the valid range is not specified anywhere.

The conditional disable symbols only define strings and it is up to the code to handle the correct case etc.

 

But I guess it would be quite easy to make a project provider that defines valid ranges that could be selected using right-click

 

/J

[hooovahh]

But I guess it would be quite easy to make a project provider that defines valid ranges that could be selected using right-click

That's what I'm thinking.  I realize the condition can be a string.  But if the value currently is "TRUE", then I can guess with much certainty that the opposite is "FALSE".  Same with 0 and 1, and other capitalization of True and False.  Personally I haven't made any conditionals that aren't effectively boolean.  I generally used them for things like when a system is designed to not have a piece of hardware.  So I would have DMM==FALSE and then the code knows not to talk to the DMM and to not show DMM manual controls.

[ThomasGutzler]

Is there a way to "Find Callers" or "Find all Instances" that excludes the instances that are currently in a disabled case of a (conditional) disabled structure?

[hooovahh]

Is there a way to "Find Callers" or "Find all Instances" that excludes the instances that are currently in a disabled case of a (conditional) disabled structure?

Not that I know of.  It could be done with lots of extra work.

[Mellroth]

Is there a way to "Find Callers" or "Find all Instances" that excludes the instances that are currently in a disabled case of a (conditional) disabled structure?

What if you use "Get VI Dependencies", with commented diagram disabled, on all VIs.

Put each dependency in a variant lookup, and then you should be able to return all callers for a specific VI from the Variant lookup.

/J

[ThomasGutzler]

What if you use "Get VI Dependencies", with commented diagram disabled, on all VIs.

Put each dependency in a variant lookup, and then you should be able to return all callers for a specific VI from the Variant lookup.

/J

 

Relative to a right click option, that qualifies as "lots of extra work"

I'll keep it in mind for one of those rainy Saturdays...