method to build exe with dynamically callable sub-vis

[LV_Pro]

Not sure if DAQmx installed, but as this machine has been regularly used for other LV2015 DAQ programs I'm guessing it is. The main program launches and performs correctly, until I try and launch the plugin from a PPL. It does work in the dev mode, and the paths, as mentioned, point correctly at the PPL on both machines (I have them in .\data folders on both machines, it works in dev mode, exe on the dev machine, but not on the LVRT machine. Not sure how to go about troubleshooting any missing components, not familiar with using PPL. As I am supposed to be "the pro from Dover" at this company ...  

[550nm]

Re: Resource not found".  If I understand correctly, the error is occurring only on the LVRT station(?)

If your plugin uses DAQmx, then DAQmx Runtime must be installed on the target/LVRT station.  For that matter, if VISA is used then VISA Runtime also needs to be installed. (These should be listed in MAX under "Software".)

When I build plugin's, the NI DLL "lvanlys.dll" is often required to accompany the DLL.

Also, when opening the plugin/VI (located in an LLB) if it's broken, the VI can be "mined" for broken sub-VIs to further characterize the problem.  If you experiment with the LLB-deployment method, the attached VI may be useful for debugging.

[JÞB]

Not contributing, just posting. To get updates.

[LV_Pro]

Me too! Bump!

[LV_Pro]

I'll have to retry the LLB method, have been trying to get the PPL method working so far this week. I'm pretty sure DAQ, VISA, etc., are installed, this is a Toughbook used in the lab for other LabVIEW based tests, utilizing all kinds of NI hardware, including CAN, cDAQ. Just read somewhere (too many locations on the interWeb looked at, having a hard time retracing my steps) of a PPL build setting that might let me look at the internal VIs. Really trying to find a relatively easy (I have to, once successful, show others how it works) means to load vis not present when the Main was built.

P

[550nm]

(I'm probably dating myself, but) when you say "DAQ" I think "NI-DAQ"...

Assuming DAQmx runtime is installed...

I'm still suspecting that the "Resource not found" refers to a missing VI or other dependency such as a required DLL.  A brute-force approach to identifying the offending code is to use the diagram disable structure to eliminate large sections of code (starting with the entire diagram to prove that the "Resource not found" is under your logic). Compile the code, so disabled; if the missing-resource problem goes away when entire diagram is disabled, then selectively disable smaller sections of code until the problem reappears.

I did a bit of experimenting with building a packed library and noticed that (as with Installers, EXEs and LLBs) a "support directory" is specified under Properties\Destinations".  If your "plugin" VI refers to a DLL, the DLL may be copied there during compile.  Make sure any such "support" DLLs are included with the PPL on the LVRT/target!

One more thing...

You might experiment with de-selecting "Remove polymorphic VI instances" (Properties\Additional Exclusions").

[LV_Pro]

Headed back to site this morning, will try these suggestions out. I really want to get a handle on the PPL or LLB technique for dynamically loading sub-vis not present when the Main was built, a proposed architecture is sort of dependent on it!

[550nm]

Considering you're expecting to update the plugin periodically, the PPL may be the better choice!

A problem with simple LLBs when updating the "plugin" (without recompiling EXE)...

Initially you'll distribute an EXE and plugin that may have some VIs common to both hierarchies. As time goes by one of these "common" VIs may get edited such that the connector-pane changes.  Now the EXE is linked to the old VI, when your plugin-VI opens expecting to load a VI with same name but different connector-pane (... and "that dog won't hunt").  Perhaps it's not an issue with the PPL - it certainly is a potential problem with LLB plugins.  Maybe someone more familiar with the PPL can help? 

[LV_Pro]

Jury is still out on my attempts to use PPL for dynamically loading vis but some new facts have come to light that muddy the water! I tried "commenting out" code, and it launched ok with all the code commented out, just momentarily showed the front panel, as it should. Added a bit of code, DAQmx initialization "stuff" and bam! No go. So I decided to try a different test of the target, built an exe where the two sub-vi's were actually in the Main, in a case statement that chose which to run. No go!!! A few weird things, on my dev machine and the target I suddenly got a "Windows Firewall" alert that the program was trying to "call out" on the net work, though there is nothing that does anything other than acquire data and save it to a file. Can't find anything that would cause that, no files inadvertently linked from the network drive, definitely no calls to the "cloud", so that one is a mystery. But more relevant is that on the target machine the main was majorly broken, missing a number of built in DAQmx vis. Hmmm, ok realized that the machine has, drum roll, Vista as its OS. And it can't be upgraded, either OS or DAQmx, so going to try on one of our newer Toughbooks, running Win 7 and with upgraded NI stuff. What was on there wasn't terribly old, it has LVRT 2015, but going to call this one for the moment until I have the new machine. It will really annoy me if it turns out that the initial attempts worked ... But that was how the whole week went.

[550nm]

It sounds like you're very close to resolving the "Resource not found" problem!

Re: Firewall pop-up.

I've seen this too!  It's... disturbing - but I've been too lazy to figure-out why it happens.  I'm guessing it's because of the default/ENABLED VI-Server/Web-server settings in the EXE's configuration .ini.  The EXEs "Properties\Advanced\Use custom configuration file" allow us to specify our own settings/file - though I'm not sure which server-setting(s) need tweaking.  (I use a custom INI to set "useLocaleDecimalPt" OFF to avoid corruption of instrument command-string formatting on European Windows systems.)