Need ideas for plug-in re-design

[CoastalMaineBird]

It does not fully solve the problem.  You still have a set of shell code that will need to be recompiled for every version of LabVIEW.

And that doesn't get me any farther down the road.

If I have an LV2010 VI embedded in my data file, then it doesn't matter whether the VI is the plugin itself, or an object VI which calls a DLL which does the plugin's work; a LabVIEW 2013 viewer code will see the LV2010 code, declare it to be old, and refuse to run it.

Now, if I could embed the whole thing in a DLL, and keep the DLL version-agnostic....

[Matthew_Kelton]

Well, similar to my idea, instead of embedding the VIs, embed the function name.  You have a VI that calls the DLL with the right function call.  The DLL no longer has to be upgraded with LabVIEW versions (but could be - as long as the right RTE is installed on older systems).  You could keep the DLL in whatever the oldest version of LabVIEW is in use, say 2010, and even the 2012 verison would call the 2010 DLL, but the wrapper is in 2012.  Since you don't embed code into the data file, it doesn't matter what version of LV created the orginal file.

[CoastalMaineBird]

You have a VI that calls the DLL with the right function call. 

Well, my first thought is that that is moving AWAY from simplicity.

I've not worked with DLLs made with LabVIEW before - do they have high performance?

I'm a bit leery of having 30+ DLLs and trying to call each one at 10 Hz.  All that overhead is something I just don't know.

And if I hve ONE DLL with 30+ functions in it, I (or rather my client) have to recompile it when they want to add a new one.

Thanks for the idea though. That merits further investigation.

[Matthew_Kelton]

I have never had any issues and sometimes have seen an increase in performance.  Since you are running source code now, I don't see it would run any worse.

The one caveat to the DLLs is also the separate memory space.  In your example, you don't show how you grab the values to do your calcs.  If they're in a global (or grabbed form a queue, etc.), the VI inside the DLL will be a copy and not reference the same memory space.