How to cope with N number of drivers without need of installing them

[jcz]

hi all,

I couldn't think of any good topic title. Anyway.

A bit of intro: I am developing an application that uses one camera. This application will be used on two different PCs. So I need 2 cameras and I have 4, but every one is different (and it could change).

So say I've got N number of cameras, each may be using different type of interface and drivers (USB with it's own DLL drivers, USB based on NI IMAQ USB driver, FireWire with ActiveX control, or one connected via BNC cable to a NI PCI-1407 framegrabber). Every single one of them needs installing a driver of some sort.

Now. What I want to avoid is an installation of all possible drivers for each type of camera. The question is how can I develop an application that is capable of using various cameras, without need of installing all drivers ?

E.g.

PC #1 will use USB camera, and it will have a drivers for it installed but not for any other type of camera.

PC #2 will use FireWire Camera, and it also have drivers for it but not for any other type of camera.

I guess the answer lies somewhere in dynamical loading of the VI's, but I am not sure how to do it correctly (in a 'what would be the best practise' way). Basically what I want to develop (in fact I already wrote it, but needs refactoring) is a VI with inputs [iMAQ image,type of camera, other settings, err.cluster] and an [iMAQ image, err.cluster] as the outputs.

thanks,

Jakub

[Shawn Walpole]

Hi Jakub,

I had a somewhat similar situation, and I'll explain what I did in case it is helpful. I used a LabVIEW class hierarchy and then dynamically loaded the needed classes. This worked well in that I could write code using the base class and not worry about which particular implementation was needed.

In the "Cluster, Class, & Variant" palette of the functions palette there is a "Get LV Class Default Value.vi" that I used to dynamically load the class I needed. I then would unflatten a string representing the configured class into the dynamically loaded default value.

In my case, the classes were always runnable because all the classes only depended on VISA. In your case some classes would be broken if the appropriate driver wasn't installed. As long as you didn't load these classes, I think you would be alright, but you might want to verify that. Also, if you are building your code into an executable then you'll need to make sure all classes are runnable on the computer you are building from.

As far as best practices goes, I designated a directory that was for my classes that the main program would scan from. I could then allow the user to pick from a list of what class to use. I ended up building this code into an executable. The dynamically loaded classes were part of the build as well. Because my classes and the executable could call common code, I ended up having the build specification mimic the file structure I used for development instead of putting all the code into the exe. This gave me a small exe with lots of vi files in folders with the block diagrams removed. I don't know if this is a good practice, but it seemed to make my life easier when the classes needed to load their subVIs.

I hope this helps. I know some developers aren't that big into classes, but they have worked very well for me when I've used them. I'll be curious to see what solution works best for you.

Shawn Walpole

[Grampa_of_Oliva_n_Eden]

QUOTE (swalpole @ Mar 4 2009, 02:16 PM)

Hi Jakub,

I had a somewhat similar situation, and I'll explain what I did in case it is helpful. I used a LabVIEW class hierarchy and then dynamically loaded the needed classes. This worked well in that I could write code using the base class and not worry about which particular implementation was needed.

In the "Cluster, Class, & Variant" palette of the functions palette there is a "Get LV Class Default Value.vi" that I used to dynamically load the class I needed. I then would unflatten a string representing the configured class into the dynamically loaded default value.

In my case, the classes were always runnable because all the classes only depended on VISA. In your case some classes would be broken if the appropriate driver wasn't installed. As long as you didn't load these classes, I think you would be alright, but you might want to verify that. Also, if you are building your code into an executable then you'll need to make sure all classes are runnable on the computer you are building from.

As far as best practices goes, I designated a directory that was for my classes that the main program would scan from. I could then allow the user to pick from a list of what class to use. I ended up building this code into an executable. The dynamically loaded classes were part of the build as well. Because my classes and the executable could call common code, I ended up having the build specification mimic the file structure I used for development instead of putting all the code into the exe. This gave me a small exe with lots of vi files in folders with the block diagrams removed. I don't know if this is a good practice, but it seemed to make my life easier when the classes needed to load their subVIs.

I hope this helps. I know some developers aren't that big into classes, but they have worked very well for me when I've used them. I'll be curious to see what solution works best for you.

Shawn Walpole

Adding to Shawn's post;

Yes investigate using LVOOP.

The Class libraries do not have to be part of the exe. You can put the appropriate Class in the right place when the driver is loaded.

Ben

[Shaun Hayward]

and now to further neBulus's post...

A technique I used to aid the distribution of the drivers was to create a build for each class (and all its subVIs, but specifically excluding the base class VIs) to create a LLB. I then put all of these LLBs in a drivers folder and used the LabVIEW list folder VI look look recursively into that folder to find all of the lvclass files (there is an input that can be used to tell LabVIEW to treat LLBs as folders). This way, one ends up with a neat distribution solution (ie all of the LV stuuff is in one "driver" file)

[jcz]

Thanks guys,

I forgot to mention that I am (still) using LabVIEW 7.1.1. I guess I should really update to at least 8.2.

I found a solution without using classes. Basically I am using a mixture of "Open VI Reference" with global variables as a substitute of "inputs" and "outputs".

See attached screenshots. It's not perfect, but it works.

Jakub

[Mark Yedinak]

Wouldn't a functional global be more flexible? As a rule I try to avoid using global variables and when I do need to use them I opt for functional globals over standard global variables. Functional globals help to minimize race conditions since only one access at a time is allowed. In addition, you can include other functionality if required.

[jcz]

QUOTE (Mark Yedinak @ Mar 5 2009, 08:02 PM)

Wouldn't a functional global be more flexible? As a rule I try to avoid using global variables and when I do need to use them I opt for functional globals over standard global variables. Functional globals help to minimize race conditions since only one access at a time is allowed. In addition, you can include other functionality if required.

Good point, I will change the global variables to functional globals.

What I tried before using global variables, was a simple change of subVI's input contol values (using VI reference > Panel > Controls[] > Name,etc. ) and then running the subVI dynamically (Invoke Method:Run) . For some reason it didn't work. Well it worked when I run the VI that was loading the subVis dynamically, however when anything higher in the hierarchy was calling the VI, all 'dynamical' subVIs had the controls set to default.