Conditional disable for runtime

[chucklippmeier]

I'd like to see something like a conditional disable structure that would be sensitive to fields in an .ini file at runtime, not compile time.

My problem is that I have an application that can access many different third party cameras. For this application to work every VI that accesses a camera specific .dll function must have assess to that .dll or I get a broken VI. When I compile the VI I have access to these .dlls but when I build an application.exe and distribute it I only want to distribute the .dlls for one of the cameras. If I could distribute a .ini file with the application.exe that indicated which camera the drivers were installed for then the application would disable the code for all the other cameras and the VI would not break.

Thank you,

Chuck Lippmeier

[JackDunaway]

You can dynamically launch those dll's in a wrapper function. Dynamic calls, rather than static calls, allow VI's to be broken at run-time without breaking the parent diagram.

[chucklippmeier]

Jack,

So to do this dynamic .dll call are you saying that I'd have to re-write every camera's VIs to use a wrapper .dll instead of the the stock VIs from the camera manufacturer or are you saying that I should dynamicly launch the manufacturer's VIs or are you saying I need to write a wrapper .dll that somehow activates a .dll that lives inside of an existing manufacturers's VI. I'm confused.

Chuck Lippmeier

[JackDunaway]

No, not a wrapper DLL, a wrapper VI (I was not clear). If the DLL is already wrapped in a VI (it sounds like it is), then all you need to do is launch that VI dynamically. You can do so either by opening a reference to the wrapper VI by file path using the VI Server "Open VI Ref" function, or you can simply drop that VI inside a static reference on the caller diagram. Once you have the reference to that VI, use a "Run VI" method to kick off the VI.

The other alternative is to use the "Call By Reference Node". The two methodologies for kicking off these VI's are synchronous and the "Fire and Forget" method... the application should dictate which method is more appropriate.

Feel free to create a post on the LabVIEW board and we can continue discussion there... the Idea Exchange is not as well suited for discussions such as these.

[chucklippmeier]

Jack,

OK, I know what you mean now and if I was looking for a way to do this given existing capability I agree that this is a way. However, this forum is for new feature ideas in LabVIEW. Personally, though I do occasionally use the two methods you suggest (actually in my camera example I use this method to choose the unique camera configureation parameters like integration time and gain).  I find them kludgy. That is, they are references to VIs that must be available to an executable in order to be called, causing configuration management problems. When one reads the code it isn't as obvious what is going on as when a VI is actually in the code. If my suggestion is implemented execution paths could be determined at runtime by variables set in an .ini file and code that was excluded would virtually not exist at runtime. At compile time the code would be clear and readable. There would be no worries about configuration management.

Chuck Lippmeier

[JackDunaway]

The configuration could still reside in a file, and once the app reads the configuration, a key could control a case structure that contains the VI ref you wish to call. In essence, a case structure is exactly what you're Idea asks for: a run-time conditional execution disable/enable structure.

I understand, you would like to take one step further and ignore compile-time errors, but by definition static calls are error-checked at compile-time, and dynamic calls are error-checked at run-time. Therefore, I think you're relegated to simply using dynamic calls within a conditional case structure controlled by the config file.

And if the calls you're trying to make are the "Fire and Forget" type, Kudos up this Idea to improve the API for this type of call. Using "Set Control Values" is a fragile code practice that should be be eliminated through that Idea.

[Intaris]

It used to be possible to launch a VI in the same execution space as an executable by calling "LVProgram.exe --New.vi" or something similar.

If this is still available, wouldn't this be a way to allow switching between different VIs for the instrument control without need for an INI file?

[chucklippmeier]

Jack,

Ya, I understand the difference and complications of static vs dynamic linking but I really don't like having to keep a bunch of VIs in a file that might be called dynamiclly. I'm hoping the NI wizards can figure out a way to staticlly link all of the VIs but if they are behind my proposed structure simply ignore them at runtime and by the way, pre-runtime. One .ini file is better than an undetermined number of VIs that may or not be called by my executable. The .ini file info could even be part of the apps .ini

You are correct that I may be stuck with "you're relegated to simply using dynamic calls within a conditional case structure controlled by the config file" but if the wizards don't consider the idea there is no chance of it succeeding.

Intaris,

Yep, that is what we are referring to as dynamic linking.

Chuck Lippmeier

[Intaris]

Funny, my idea of dynamic linking is opening a reference to a VI and launching it from within the program itself.

IIRC, my idea can be implemented without ANY code in your program.  It used to be an inherent property of LV exes (and was actually a security risk), but I don't know if it still works since much has been changed in this regard.

What I was referring to is not what I would call dynamic linking.... mabe I'm wrong??

[chucklippmeier]

Intaris,

Oh, now I know what you mean about the LVProgram.exe now called System Exec.vi. This vi can be used to execute any program LavIEW or not. and sure if I wanted to have another LV program running I could call it using this VI. However, what I'm trying to do is select which camera to use in an application that processes the image obtained by the selected camera. Since the camera would be installed independent of the LabVIEW application and since the alternative cameras may not, the application breaks at load time when it can't find the .dlls for the uninstalled cameras. I can install the other cameras .dlls but I'd rather not. Also, I'm trying to avoid a directory full of VIs that may or not be called either as you say dynamically or for that matter by the System Exec.vi method. I really only want one .exe to deliver to the client with everything in it, but if the driver for the camera is not installed then the application ignores the broken VIs inside instead of breaking the top level .exe.

This all talks about what a LabVIEW programmer can do and when he can do it. In a CIN you can write a function to do things at Load time but not in LabVIEW without a CIN. LabVIEW has load time but doesn't give us any tools to deal with it.

Chuck Lippmeier

Chuck Lippmeier

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.