LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

PlugIn architecture and deployment

All seems to be working, I added the files as a seperate file during the build and gave them a specified destination, built the application and deployed it, things are working now.  Learn something new each day.  I will try to write another data filter save it and add in (place it in the plug-in folder)  and see if the application recognizes it.  Thanks,

 

Paul

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 11 of 18
(1,964 Views)
And don't forget to post the result... 😉
Using LV8.0
--------------------------------------------------------------------
Don't be afraid to rate a good answer... 😉
--------------------------------------------------------------------
0 Kudos
Message 12 of 18
(1,962 Views)
Since it looks like this is all figured out, I'd like to add a little tidbit.
 
The dynamicly called VI can be called without any special compiling provided the LV-RTE is the same version in which the VI were called.
 
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 13 of 18
(1,959 Views)
Just to clarify - by "compiled" I meant that the VIs can be run in LV, that they can find all of their subVIs and that they were saved. Once a VI complies with these demands, it can be run from the RTE.

___________________
Try to take over the world!
0 Kudos
Message 14 of 18
(1,955 Views)

KEY WORDS DAQ-MX APPLICATION BUILDER PLUGIN ERROR 1003 LV7.1

Hi I have been having issues with this type of application.  Basically this is what i have a Main program that calls other vis.  I am trying to use the plug in architecture and dynamic loading, both taken from the examples and modified for my use.  I have been having a lot of issues until i compiled the daq files into the exe from applicatioin builder now i can load more of the plug ins. 

I have tried mass complialing.  I have tried creating stubs, modifing the dynamic loaded vis so that they come up nutered.  I have checked and insured that all the vis function.  I know that i am using a development and deployment computer so that on the development computer due lack of hardware some vi will imediately stop, they are expecting certain comunications and time out. 

I put the following( plus the file location of the dynamic files) in the config file of the executable. 

C:\Program Files\National Instruments\LabVIEW \vi.lib

However i only appear to get a better level of operation by including

C:\Program Files\National Instruments\LabVIEW 7.1\vi.lib\DAQmx

using the add support file.  Can some one tell me why and what i need to do so i don't have to have all the vi i want to attach dyanmically loaded. 

0 Kudos
Message 15 of 18
(1,851 Views)
I'm not sure if this will help you, but this is what I know (in brief) about compiling and dynamically loading VIs.  This information has come from playing with dynamic loading from compiled (.exe and .dll) programs from LabVIEW 7.0 to 8.0.1.  I've not played with 8.20 yet, so some of the below may not apply anymore.

Dynamic loading works without any issue so long as the VIs are started from the LabVIEW (not run-time environment) executable. Things get interesting soon as you go to a run-time environment.

A compiled (.exe) VI can only dynamically load the VIs that have been listed in the build specification.  The dynamically loaded VI and all of it's subVIs and support files are compiled along with everything else.  The key here is all the support files such as the DAQmx VIs.  An example of when I use this method of dynamically loading files is when I want a debug screen in the execuable; the VI that is the debug screen is normally not executing unless it is started by using VI server to load the debug screen VI and start it executing.

There is a caveat to this...

A compiled (.exe or .dll) VI can call a VI inside of a DLL and not have the dynamically loaded VI in the build specification.  You do have to have the full path to the VI inside the DLL.  For example, the VI dynamic.vi located inside the DLL "C:\Temp\test.dll" would require the path "C:\Temp\test.dll\dynamic.vi".  I will note that I've not done this technique in quite some time (early testing in LabVIEW 7.0), so there may be something I'm missing here.

A non-compiled VI can dynamically load a VI in a DLL in the same manner.  This technique I use regularly to help copy-protect and user-protect code.

There is a technique which I've not tinkered with that may produce good results.  It appears to be possible to create an application reference to the LabVIEW program and use this to dynamically load a VI on the localhost machine.  I've not made this work yet, but then again I've not had much time to play with it.  It appears the JKI VI Package Manager program may use this technique.

Then there's gotchas with dynamic loading and memory space and LabVIEW 8.0, but that's a whole different topic.
0 Kudos
Message 16 of 18
(1,836 Views)
Phi,
     Its really strange, i have two versions( call them a and b).  Each version has a number of plug ins.  The trick for me has been getting the dynamic loader to load say b.10 and only b.10.  I have narrowed it down to the following. 
 
C:\Program Files\National Instruments\LabVIEW 7.1\vi.lib\measure\mascope.llb
 
So i have tried adding this file as a "Support File" but that has not panned out at the moment.  I'm starting to wonder if there is an issue with their linker when they make VIs.  Or how the EXE will function when the LabVIEW environment is not present. 
 
I have attached the containing VI.  If your curious try making an EXE of it and dynamic loading it.  It seems to puke due to the Pulse Measurements.VI 
Thanks for your response and I think i'll beat my head against this for a bit longer before trying the DLL approach. 
 
Thanks
0 Kudos
Message 17 of 18
(1,823 Views)
0 Kudos
Message 18 of 18
(1,821 Views)