LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Creating Plugin Modules for Use with Compiled Code

Hi all,

 

While programing a data analysis package in Labview, I've run into a problem that I don't really know how to answer.  It goes something like this: my program receives data from measurement devices in the form of ASCII or binary files, which I must then process and evaluate.  The problem is, the data files can have a variety of different formats.  Right now, I only know of 4 or 5, but more could literally be added at any time.

 

My thought is this: I'd love to have some sort of modular plugins for reading the data files.  In other words, I could have a subfolder under my application's space in the "Program Files" directory.  The subfolder would contain any number of "ReadFileX.xxx" modules.  Upon initiation, my code would scan that folder, determine the possible formats (based on the *.xxx files therein), and be capable of reading any of the files.  Ideally, the user would select a file, I would note its format, and call the appropriate plugin module to handle reading the data into my code.

 

What is the best approach for doing something like this?  I looked (briefly) into using DLL's, but (from what I can tell) I would need to explicitly define the function name and the inputs / outputs in the "Call Library Node" function.  This would appear the break the modularity feature, as I want to be able to load the software, and then develop new plugins down the road when the need arises.  I also found some information on source distributions (in an LLB).  This option would probably work, but my efforts at coding a basic test of VI-Server were met with errors.

 

Does anyone have any experience performing a similar task?  If so, would you share your knowledge / secrets with me?  I would be extremely grateful for your feedback.

 

Thanks!

 

Mark

0 Kudos
Message 1 of 9
(4,208 Views)

Hi Mark !

 

This is a typical case where LabVIEW Object Oriented Programming would be very useful !

 

I think you should have a look at Dr Damien's Development : http://forums.ni.com/t5/LabVIEW/Dr-Damien-s-Development-Object-Based-File-I-O-I-Representative/m-p/1...

 

And of course looking for LabVIEW OOP on google and ni.com site would be very usefull !

 

Also, you have tons of example in the LabVIEW example directory (Program Files > National Instruments > LabVIEW > Example > LVOOP), especially the "Graphics" example which could illustrate what you want to do.

 

Regards,

Da Helmut
Voir le profil de Maxime M. sur LinkedIn - View Maxime M.'s profile on LinkedIn
0 Kudos
Message 2 of 9
(4,202 Views)

Mark - there is a Coding Challenge currently going on, and I have submitted an entry that shows how to dynamically instantiate a class based on a class that resides on disk. Specifically, you're going to be interested in "Get LV Class Default Value.vi" under the "Cluster, Class, and Variant" palette that allows you to create an instance of an object based on the path of the .lvclass file. The class you load is going to be what's called a child class of a parent class (or base class), where the child class implementation overrides the function of the parent class. The "Get LV Class Default Value.vi" is very loosely analogous a Class Constructor.

 

You can deploy your application having implemented all the base class functions, then subsequently develop and deploy new classes to reside in a "plugins" folder without needing to change the original app code.

 

If you find that contest entry helpful, consider dropping a vote, huh? Smiley Wink The LabVIEW Communities have had access errors sporadically the past few weeks, so if you get a "Server Error" you may need to try again later. There's also going to be Forums maintenance today and tomorrow.

Message 3 of 9
(4,194 Views)

pdf about plugins in LabVIEW

 

LVOOP makes for a good plugin system. You implement the plugin interface as an abstract class. Then use "Get LV Class Default Value" to load the class, then down cast it to the plug in interface and away you go. The tricky parts are being careful with vis that have multiple version between plugins (which ever version loaded first is used for all plugins). The other tricky part is packaging the plugin. I think you can make it as a source distrubution, the packed library option in LV2010 may also be an option (I haven't tried).

Message 4 of 9
(4,192 Views)

 


@matt W wrote:

pdf about plugins in LabVIEW

 

You implement the plugin interface as an abstract class.


The base class does not necessarily have to be abstract, it can implement default actions. This is desirable (required, even?) for Dynamic Dispatch methods that are *not* marked as "Must Override", and for those that are marked "Call Parent Implementation".

 

Message 5 of 9
(4,188 Views)

I'd call a class without any default actions pure abstract, and one where at least one needs to be overwritten abstract. But that definition is from my C++ background. But even with my defination of abstact you wouldn't need a "must override" (labviews version of abstract in my mind) method. So your correct it doesn't have to be abstract. I suspect most plugin interfaces should have some must overrides in it.

0 Kudos
Message 6 of 9
(4,174 Views)

Thank you to all of you for the informative posts.  In the past, I've shied away from OOP in Labview because it scares me.  However, 3 votes of confidence on the same topic means I need to get to work and learn something.  I'll look into OOP as you suggested, and post again when I come up with something.

 

Many thanks,

 

Mark

0 Kudos
Message 7 of 9
(4,150 Views)

Does anyone know if there is a way around the "Get LV Class Default Value" VI loading the entire class into memory?  Basically I am looking for a way to dynamically load a class an only use a few method on it.  Since dynamic dispatch VI's cannot be called by VI Server I appear to be stuck.

 

In a nutshell, I have a hierarchy of child classes that all have say (Initialize, Process, Close).  I want to dynamically load the right class and just be able to call these items without loading the entire class into memory.

 

John

0 Kudos
Message 8 of 9
(3,835 Views)

Hi Rammer,

 

After reading through on the documentation of that VI it appears to me that it only loads dependent VIs into memory. In my experience with object oriented programming the dependent VIs will include all of the parent classes and loading partial classes into memory does not appear to be possible. I am going to keep looking into this issue and will respond here if I find any alternative way to acheive the functionality you are looking for.

Patrick H | National Instruments | Software Engineer
0 Kudos
Message 9 of 9
(3,813 Views)