Exclude unavailable Toolkit or Module code parts

[comrade]

Hi,

is there a best practice for excluding (disabling) code that requires unavailable/not installed/deactivated toolkits or modules for LabVIEW?

The background is integration of a new testing project into an existing inspection software that widley uses NI Vision Development Module, whereas this new project will not rely on vision whatsoever. Of course, on our development machines there will be no problem, however, when compiling the project in to an executable, this executable will only work with an activated Vision Deployment License that the customer would have to pay for, in some way.

Our idea is to use Conditional Disable Structures with a key like "Use_Vision". So far all VDM VIs can be successfully excluded. The problem are the CTLs used by VDM: Image Display and IMAQ Image.ctl - they appear in a vast number of SubVIs and also in the main data structure TypeDef - this will always break the code whenever VDM is not installed or the Deployment License is not available on the target machine.

So far I can see three ways of dealing with the situation

1. make the customer pay for the Vision Deployment License
   --> obvious downside here
2. change IMAQ Image.ctl to string element and Image Display to Intensity Graph
   --> code is required to adapt from Image type to correct display of 2D Data so everything present will function properly as it had before that change
3. delete all VDM content and just develop without it
   --> new branch of inspection software that has to be maintained in the future

Does anyone know a different, more practical approach? Thanks for your time, thoughts and input.

Falk from Germany

[Bob_Schor]

I don't see how you can develop software to run on a Customer's Machine that requires licensed Vision Deployment License without getting someone to pay for the License.  Of course, you could simply buy it yourself and "bundle it in" to the price you quote your customer.

As to coming up with a way to have the Image Controls present without having the entire Vision Library present, make a duplicate Library (I'm not sure what to call it, maybe EyeMAQ) that has an LLB with IMAQ Image.ctl and Image Display.ctl.  I found IMAQ Image.ctl inside the folder \LabVIEW 20xx\vi.lib\vision\Image Controls.llb, which also has other TypeDefs.  You could extract it and put it in an LLB of your own making.

I have no idea if this will actually work, but it might be worth "doing the experiment" to find out ...

Bob Schor

[comrade]

Thanks Bob for the answer. That "Custom llb" might actually work. One would have to check whether such procedure is covered by NI's license agreement.

Concerning the first part of your answer, perhaps I expressed myself a bit unclear. I want to exclude the Vision Module. The current customer will not use any vision content. But we want to use/adapt a software we developed for Vision use cases and disable all Vision content in order to make it compilable and executable without vision being installed and still keep the Vision functionality for future use. It's nothing to do with wanting to use the Vision Module and not having to pay for it.

[Bob_Schor]

Hmm.  I think I've done this by defining a "Sim Camera" "Constant VI" and wiring it to a Case or Conditional Disable structure to remove references to Vision routines.  I may have a test system set up without Vision -- if so, I'll try to disable the Vision calls and see what happens ...

Bob Schor

[comrade]

I'm not sure what you mean by " Sim Camera" "Constant VI". Anyway - exclusion of Vision functions works nicely by putting them into a Conditional Disable. Also - the wire data type doesn't break anything. The only headaches are Image Display and IMAQ Image.ctl - they have to be present in order for a VI to become compilable / the executable to be able to run.

There might be a chance one could install Vision and leave it unactivated. The controls are there then. However I'm not sure if licensing is mandatory for controls...One way to find out, unless anyone can save me the trouble

[Bob_Schor]

"Sim Camera" (for Simulate a Camera) is the name of a VI that outputs a Boolean.  Inside the VI, you wire "T" to the Boolean if you want Simulation On, and "F" to the Boolean if you want Simulation Off.  Because this VI essentially "exports a named Constant", I call it a "Constant VI" (sorry for using unfamiliar and undefined BS terminology).

The reason to make this a sub-VI is you can use the Find function to find them all when you need to do so.  Use them as inputs to Case or Conditional Disable code, with IMAQdx functions in the False case (where you are not Simulating, but using "real" Vision code) and nothing, or code to create "image-like arrays", in the True cases.

Bob Schor

[Hooovahh]

I thought the conditional disable would have worked.  What about your build spec settings?  There is disconnect type defs, and polymorphic VI settings.  Maybe changing these would help build an application that really doesn't need that toolkit.

[comrade · Accepted solution]

Hi all,

thanks Bob for enlightening me. I have used an "offline?" switch before, usually from the outside with an .ini-file. The idea to put this variable into a "constant" SubVI to more easily find all the places this switch has effect is absolutely ingenious, as it is so simple. Thanks!

Hooovahh:

I hadn't thought about that. Definitely worth a try to use disconnect from type def...

I'm currently out of the office and it will be some days when I can try it all out. I'll be back with news. Thanks for all your help.

[comrade]

Just a short notice on how things stand:

We got a special permission from NI Germany to install but leave unactivated the Vision Development System in order for the application to run, as we are not using any Vision functionality in this case. So problem solved. Kind of.

Now I made a test installer to see what kinds of installers LabVIEW recommends for the application to be built. Turns out, it still recommends the Vision Runtime. But I noticed when deactivating the "automatically choos installers" (or something) checkbox, that I could disable the vision Runtime but keep the Vision Common Resources Installer, see attached screenshot.

Would this installer be the very thing I was looking for? No need to activate it and providing all the CTLs the app is containing (but not actively using)? Any ideas about this?

Unfortunately it is rather hard for us to test this stuff as there is no PC around that's unaffected by LabVIEW and where we have administrator access to.

[JÞB]

I'm no legal expert but,   it seems to me that you are going about this less than honestly.   You should consider paying for either the vision license or the additional cost of forking your code base.  You can decide which way is more cost effective.  And you maintain a reputation as being ethical without wandering though grey blurred terrain.