Pointing to VI Refnums that will change

[dacad]

I have an elaborate test application that will test many different models of product.  Each model has it's own test criteria and test methods.  To this end, I essentially construct a full sub-vi for each model that pulls the test criteria from a database and contains a state machine to utilize a group of standard vi's for the correct series of test methods.

In my source code version, I point to a specific sub-folder where the model specific sub-vi's are located.  My situation now is that I am looking to create my executable and I have to make some decisions about what to do with these vi's as I will continue to add new ones as new product models are introduced into production. This could happen multiple times a week as the move to automated testing accelerates.  The way I see it, my options are, in no particular order:

1)  Compile all the custom sub-vi's in with the exe which would then require a fresh exe be created everytime I needed to add (or edit with an Eng Change) one.   Not a good option I think.

2)  Keep the vi's in source code format and keep them located in a sub-folder under the main exe.  Seems a bit uncontrolled in case someone inadvertently opens one and changes it.Also messy when I go to multiple test systems.

3)  Place the sub-vi's in their own library that can be maintained independent of the main exe.   This seems to be my leading candidate right now but I have never created a library file to use with an exe and I don't know how to tell the main exe to point to the subvi's that would be in the library file.  Also, would a library file be better than a dll?  Not sure the pluses or minuses of one to the other.

4)  I don't know yet

I have attached a pic of the routine I am currently using to access the subvi's.  The Test_Selection points to the "Custom" state case and the Part_Number becomes part of the string that creates the file path for the current location of the sub-vi needed.  The global variable "Custom Test Folder" is the location for all the custom sub-vi's currently. (Broken arrow is for other part of app I am working on)

I use a Type Specifier for VI Refnum that feeds into Open VI Reference that uses the assembled path to decide which vi to open.  This feeds to Call by Reference to run the sub-vi needed.  All sub-vi's will have an identical terminal block configuration for feeding the assorted parameters and such. This method has worked flawlessly for the time it has be operated from source code.  I just need to move it forward into an exe so I can start using it on more systems.

Any thoughts on this are very much appreicated.

Doug

[Mark_Yedinak]

I would suggest using packed libraries and a plugin architecture. That way you can easily add new devices. You may also want to consider using LVOOP with dynamic dispatch. You may want to look at some of the informatoin here for some examples.

[pobrepablo1]

I think you should look into LVOOP (object oriented programming)

I have a lab program that runs hardware which is unknown at runtime - the main VI is completely agnostic; a database is read, and the hardware is then chosen so that the corresponding tests and such are done dynamically. I do this via dynamic dispatch VIs and classes. I have:

parent Device Class

 - inheriting classes:

     -device type A

     -device type B

     -device type C 

     -etc

So that whenever our company manufactures  a new device, I just need to add a new sub-class and I'm done. No hunting all over my main VIs looking for places where I call specific instances.

Sounds like you need dynamic dispatch VIs for your tests.

[dacad]

Just to clarify, I am not adding anything to the test system, just adding alternate versions of the sub-vi that controls the testing of our product.  The sub-vi's vary with different parameters, different test methods, different test sequences, etc.

I am looking intothe VLOOP stuff to figure out how difficult it will be to implement into my current application.

Thanks

Doug

[dacad]

OK,

Have been looking into the VLOOP and while it seems it is going to take some serious time to work through all the fine details of this, I did a short example and it appears that it really doesn't give me anything but more overhead when all I need to do is identify and call the specific version of test code I need to run.  This appears to be way overkill for my purposes. Might look cool on the block diagram but looks like it will involve more coding than if I choose something more old school.

Generating the path or other type of locator will be the easy part of the task.  I just really need a simple way to point to where the code is and then to execute it using the assorted inputs I provide as the initial post shows.

I would like to see how using a packed library file would work I just need a little help with the syntax for pointing to the library file and the specific code located in the library file and then how to pass the inputs and outputs through.

If anybody can point me in the direction of some examples I can analyze I would appreciate it.

Doug

[pobrepablo1]

Take a look at the Board Testing example VI (Help->Find Examples) Compare and contrast LVOOP (LabVIEW object-oriented programming) method with the more traditional approach. 

That example is amazing and really showcases the usefullness of LVOOP. It helped me tremendously - I was initially like you and thought "what a waste / how unnecesssary" but give the example a shot. 

[dacad]

Ok,  problem with packed library file.  This from the LV help file:

"Include only related VIs in a packed library. When you open a VI in a packed library, all VIs in the packed library load. If you include non-related VIs, load time increases because more VIs need more time to load."

I will have dozens or more different vi's in the packed library.  The intent is to open only the one that is needed for the test routine required at the time to reduce overhead.

Is there a different "container" that I can use to locate all the different test vi's?

If I have to go back to VLOOP I will but I would expect there is another way to accomplish what I need.

And in using VLOOP,  what container (other than a packed library) would I use so that when I add/modify test vi's, updating the remote systems is a matter of replacing a single file on each system.

Again,  any thougts are appreciated

Doug

[dacad]

Ok, excuse my dyslexic spelling of LVOOP

Doug