Example Code

Simple Plug-in Architecture: The Most Complicated Calculator Ever Conceived

Code and Documents

Attachment

Download All

Introduction

Plug-in architectures are useful for creating extensible programs that don't need to be recompiled for minor changes.  While quite useful, many LabVIEW programmers are intimidated by the perceived complexity of such a design.  This VI demonstrates a very simple implementation of a plug-in architecture.

Steps to Complete

The basis of a plug-in architecture is calling VIs dynamically.  This VI will search a functions folder for VIs.  These VIs will then be added to the list of available functions for the user to select and the appropriate VI will be loaded and run when the "Calculate" button is pressed.

Front Panel.PNG

Block Diagram.png

Additional Notes

Any VIs added to the functions folder that have the correct connector pane will be added to the list of available functions at run time.  The VI output99.vi has been included for demonstration purposes.  Move this VI into the functions folder to add its functionality to the calculator.

Applications Engineer
National Instruments

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
tomlawton
Member
Member
on

Chris- We've done this for years and years.... BUT... How do you do it for built applications.....? I've seen a note about it in the past, but never got around to following up...

Thanks,

Tom

soupy
Member
Member
on

this approach will work fine for built applications as long as the function VIs do not have their compiled code separated from source code.

i would highly suggest redoing this example in OOP using the factory pattern. you'll get the exact same functionality as above, with the added benefit of the enforcing strict interface requirements on the individual functions. in the non-OOP method, your functions can have incompatible connector panes and you won't know until you attempt to execute it.

tomlawton
Member
Member
on

Ahaaaa!

as long as the function VIs do not have their compiled code separated from source code

That's one good thing to know; bit of a pain under version control, or course....

Also, for clarification, would the plugin VIs folder and contents be compiled in, or sit, uncompiled (or compiled?), outside the exe..?

soupy
Member
Member
on

the plugin vi folder can sit uncompiled as *.vi files as long as the compiled code is included. or, you can "always include" them in the build and you don't have to worry about it (but your path will change a little bit)

if you normally separate compiled code, you can fix this via post-build scripts. i've never done them, but this is how i'd fix this problem.

tomlawton
Member
Member
on

the plugin vi folder can sit uncompiled as *.vi files as long as the compiled code is included.

Very cool! That'd allow us to deliver a built main architecture, and permit ad-hoc code to be delivered as-and-when.

"always include" them in the build... ...(but your path will change a little bit)

Yep, that's what happened when I tried before. Bit of a pain, as we'd like to run the code both built and un-built. I'm sure we could detect which we were(?), and dynamically adjust paths accordingly...

if you normally separate compiled code, you can fix this via post-build scripts. i've never done them, but this is how i'd fix this problem.

Great idea- I'll look into that!

soupy
Member
Member
on

i should also point out that, as of labview 2012, NI is starting to get away from including compiled code with the VI by default. I don't have anything to back this speculation up, but it could mean that at some time in the future they could remove this feature entirely (again, just speculation). if it were removed, i'd assume that it will be replaced by some equivalent feature. this is something you should consider if you are creating a long-term architecture. I'd suggest a chat with your NI rep if you see this as a potential issue.

PhilG
Member
Member
on

I vaguely recall that there is a way to directly paste the diagram shown to become a new VI.  Can anyone refresh my memory?

tomlawton
Member
Member
on

Something about "snippets"..! And I couldn't remember it either so I just downloaded the archive...! I did wonder if the image was actually a screenshot of a snippet- since all the drags or image copies I tried failed...

guangdew1
Active Participant
Active Participant
on

Tried to make an executable but couldn't bring the functions folder and the included files. Anyone knows how to make it?

tomlawton
Member
Member
on

Chris- hijacking this a little... Is it still possible to run un-built VIs (with object code included, of course) under the current RTE?

I remember it used to be possible- this http://www.ni.com/support/labview/toolkits/appbuild/lvrte.htm confirmed it- but a quick check just now (LV2011) didn't seem to work.

What got me thinking about this was your mention that the plugin VIs need not be executables; and the fact I have a codebase that started back in LV2.0, that as a result really doesn't lend itself to being compiled....

guangdew1
Active Participant
Active Participant
on

Tomlawton,

I capied the functions folder into the executable location (with original LabVIEW code, not compiled) and it worked. But it's still the development environment, I don't have the pure RTE environment, I think it will work in the RTE environment. Looks uncompiled LabVIEW code will work in the RTE environment, of course we couldn't edit the code. I will try it when I have it.

tomlawton
Member
Member
on

I did try with a fresh machine, and only installed the 2011RTE. I put a .vi on the machine, and Windows didn't even give it a LabVIEW icon- and certainly wouldn't run it, sadly. So either I'm doing something wrong, or the functionality described at

http://www.ni.com/support/labview/toolkits/appbuild/lvrte.htm no longer exists.... Interesting that (according to Chris) a "raw" .vi will run if called from a compiled executable- I'll have to try that on my RTE-only machine....

soupy
Member
Member
on

it works fine with 2010 SP1. we use it every day

soupy
Member
Member
on

oh, be sure that your path to the functions folder is correct. the paths are a little different when you put it inside an exe. if you're still having issues, compile to exe with debugging enabled and use remtoe debugging to probe things.

tomlawton
Member
Member
on

Yep- I can imagine that plugin folder paths get a little tricky, as you have to climb up out of the exe before you can descend into the filesystem, from what I remember.

So the question is- why can't one run an uncompiled VI directly under the the RTE....?

guangdew1
Active Participant
Active Participant
on

I think it's just the relative path. Wherever the calculator executable is, put the functions folder right by it, the program will file the files.

Albert.Geven
Trusted Enthusiast Trusted Enthusiast
Trusted Enthusiast
on

Hi

First of all there are no uncompiled vi's. There are vi's with the code inside and vi's with the code in the cache folder.

The problem is that the RTE cannot finde the code in the cache folder. I'm also looking for a solution

but don't have one except uncheck the "separate code from VI"option.

greetings from the Netherlands
tomlawton
Member
Member
on

Sorry Albert- bad semantics on my part; "un-built" is perhaps a better term!

As far as cahced object code, "soupy" made it clear that the compiled code must not be separated from the VI; however, even with the object code on-board the .vi, it wouldn't run (for me) under the RTE... It may simply be a registry issue, since the .vi file doesn't even get a LabVIEW icon.... But I've not found a (for instance) lvrte.exe I could associate the .vi filetype with. I think things have changed a little since the instructions for LV5...

Albert.Geven
Trusted Enthusiast Trusted Enthusiast
Trusted Enthusiast
on

LV5 also had dynamic loading but indeed is very old.

You also need the lv5 rte and I don't know if it is still available.

greetings from the Netherlands
Contributors