LabVIEW
Plugin/Modular architecture without using OOP
Ok, first I am aware of the benefits of using OOP.. but for this task I can't use it. I know this is a can of worms but here we go.
Here is and example of what I am trying to accomplish, look the Queued Message Handler with continuous Data Acquisition (Create Project -> Templates -> Continuous Measurement and Logging). If you were to take the lvlib for the Acquisition (Acquisition.lvlib), make 2 copies (say one is used run System 1 and the other is to run System 2) giving each a unique name, how would I load them dynamically at startup? (going to try to asynchronously launch the main ...)
- The interface to communicate down to each and back from Acquisition is and will remain the same. So I can handle addressing each one based on what queue is used...
- I would removing the call out to logging. That would be handled elsewhere.
- I could extend this to handle X of these modules.
- Each module could have multiple versions available or I could dynamically load what is needed based on a requirements file.
Put your mind at ease, I will not be using the Acquisition.lvlib.. well at least not in it's current form.
I have been searching here a LavaG but everything I have found is based around OOP.
So in summary:
1. How do I launch a lvlib (or something similar) dynamically?
2. Do I need to do anything special for the build of the lvlib for development / deploy phases?
Thanks everyone, Ryan aka R^2
@R^2 wrote:1. How do I launch a lvlib (or something similar) dynamically?
You don't. You launch a VI inside a library. The VI has a full name\path, including the library.
@R^2 wrote:
2. Do I need to do anything special for the build of the lvlib for development / deploy phases?
Yes, you should make sure everything that is needed by the library is available in the executable.
You might want to look into packed libraries... It's this problem they are trying to solve. With mixed results, but better then the alternatives, AFAIK.
Search LabVIEW like a graph! 
This is a pain without using OOP. Why is it restricted?
I think without using OOP the way you would want to do it (the easiest off the top of my head) would be like my small example below (its not launching something but is a demonstration). You would dynamically create the path to a vi using the different PPL's. You then launch that vi, set the controls, and run it. Then you read back the controls to get the values back. You can also open front panels and other things this way.
Just wanted to add, another vi that might be useful is called "Get Exported File Path.vi"
@ShockHouse wrote:
This is a pain without using OOP. Why is it restricted?
They have given multiple reasons but I think it boils down to a previous developer using a different language did a project for them using it that doesn't really work and no one else can now use or modify... I know this is going to be painful initially...
@ShockHouse wrote:
would be like my small example below
and
@wiebe@CARYA wrote:
You don't. You launch a VI inside a library. The VI has a full name\path, including the library.
So like most people do subpanels on a UI...
What format should I use so the modules are not compiled into the main application?
@crossrulz wrote:You use strings and paths to open your dynamic VIs, not static references.
Sorry I wasn't clear on what I was asking... thinking through what I need;
My modules need to be compiled (I don't want to give access to the source code) but I want them to be compiled separate from the main application. This should allow the module to be used as plugin to the main program and called dynamically at startup. I envision a folder of these modules/plugins that the main program is told which to use at run-time.
What format (ppl, llb, ...., something else) should I use to compile the module/plugin?
PPL (format .lvlibp).
That's what I use extensively in the applications I develop for plugin based systems. They are compiled and binary, so unless they have the development system they can't look at the Black diagram, Front Panel.
Packed Project Libraries (PPLs) are definitely what you want. As stated, they are libraries that have been compiled, something of a mix of llb and dll. As long as you are very careful about dependencies in said PPLs (ie if PPL A has to call PPL B), then they are simple to use. But if you have inter-dependent PPLs, you need to be very careful about having separate projects and maintaining relative VI calls in the builds.
Ok I think I have it worked out... I will post example code once I have the demo worked out.
For the intent of what needs to be controlled this is going to work pretty good... from a developers point of view this is going to be a bit of a pain to develop in.... Lots of separate projects and builds.
