Error 1003 - Subpanel happily runs VI in Dev, won't Run when Executable

[DailyDose]

LabVIEW 2020 SP1

I've created a dynamic plug-in system using sub-panels.  It calls instruments and various other VIs designed to be asynch plug-ins that are reentrant.  It runs nicely in Dev mode.  As an executable, it refuses to run any of the plug-ins.  I've littered my code with file/folder location indicators to make sure all the subpanels are calling the VIs from the correct locations.  So please trust me when I say, the VIs paths are correct.  As an experiment, I did the following: I created a random VI that only runs as a timer and runs for 10 seconds.  I've placed the VI in a specific location and hard coded the filepath.  I test it in Dev mode to guarantee it works.  I run it in executable (run-time) and get error 1003.  What am I doing wrong?

The asynchronous call and running in the SubPanel (this is a solid representation of how  the plug-ins are being called):

This is the Timer.vi (the plug-in config info is a type def, I've tested this with it connected and disconnected from the type def)

This is it running on the main FP in the Dev environment: (the plug-in config info is usually populated, but not necessary in this scenario)

This is it erroring out as an executable despite the VI being a hard coded location and me running it as Administrator:

Does anyone have any suggestions?  Yes I am digging through old forums and NI's 1003 error code suggestions.  No I cannot share my code - if I could, what exactly are you looking for?  There's obviously something I'm not doing correctly.  Or maybe SubPanels just aren't as wonderful as I had hoped.

[JÞB]

One quick suggestion.  Look at the VI Properties settings in the build spec for the application.   Did you use the "default" settings for the subvis you are loading into the subpanel?

Yeah, that removes the targeted subvis Front Panels and makes it really hard to load the missing diagram.  In fact, you'll get an error 1003 when you try. 😀

[DailyDose]

Based on what you've said...

---

@JÞB wrote:

One quick suggestion.  Look at the VI Properties settings in the build spec for the application.   Did you use the "default" settings for the subvis you are loading into the subpanel?

Yeah, that removes the targeted subvis Front Panels and makes it really hard to load the missing diagram.  In fact, you'll get an error 1003 when you try. 😀

---

Do I have to build the plug-ins along with the executable?  They can't just be simply VIs that I make whenever I want and then call into the executable subpanel when I think they're ready?  They actually have to be built with the app?

[JÞB]

---

@DailyDose wrote:

Based on what you've said...

---

@JÞB wrote:

One quick suggestion.  Look at the VI Properties settings in the build spec for the application.   Did you use the "default" settings for the subvis you are loading into the subpanel?

Yeah, that removes the targeted subvis Front Panels and makes it really hard to load the missing diagram.  In fact, you'll get an error 1003 when you try. 😀

---

Do I have to build the plug-ins along with the executable?  They can't just be simply VIs that I make whenever I want and then call into the executable subpanel when I think they're ready?  They actually have to be built with the app?

---

Your subvi must be in a compiled state somewhere to be called from your exe.  

•  in the exe build spec
•  in a dll
•  In a packed project library (lvlibp)

Basically somewhere where a dev environment cannot make any changes to it... My God! Could you imagine what would happen if the targeted code was edited!  No! Stop imagining that before you go insane

[DailyDose]

---

@JÞB wrote:

---

---

Your subvi must be in a compiled state somewhere to be called from your exe.  

•  in the exe build spec
•  in a dll
•  In a packed project library (lvlibp)

Basically somewhere where a dev environment cannot make any changes to it... My God! Could you imagine what would happen if the targeted code was edited!  No! Stop imagining that before you go insane

---

I know a company I used to work for would just drop VIs into a folder for Test Stand.  "Uncompiled."  And it was fine because there was no development environment on test racks themselves as is the general practice.  Allowed us to update things on the fly.  I had promised management that the executable wouldn't need to be updated with each plug-in update, but maybe I am apparently full of it?  Is there a white paper on proper plug-in etiquette for LabVIEW deployment?  Goes over things one must do in the building process?  I found something for NXG, but - I don't want NXG and it wasn't entirely helpful.  

[JÞB]

The TestStand application instance calls through the module adaptor to a proxy caller into the LabVIEW IDE or RTE. <gross oversimplification >   This does require that TestStand check the module protype at runtime and error when it has to protect itself.

The LabVIEW RTE does not typically use a proxy caller....[I once heard a evil spirit whisper that perhaps if you navigate to the 3rd or 4th sub basement......] don't look 👀

An exe can call into a ppl that exists outside the application.  Those ppls are often used as plug-ins by placing them in a plug-in folder.  You can even dynamically list the folder contents and select a dynamic process from the plug-in "Store."  Each ppl can always be updated and deployed and contains version information. 

That means that, in theory, you can easily create some sort of test configuration file driven application that sequences through actions to complete a process that may change dynamically between runs.  The developer hours needed for suchlike stuff is not really difficult at all.....until you need 1 more feature in your custom test executive.

[Kyle97330]

---

@DailyDose wrote:

---

Is there a white paper on proper plug-in etiquette for LabVIEW deployment?  Goes over things one must do in the building process?  

---

Not really a white paper but there is this:

Effectively_Using_Packed_Project_Libraries_SEPAD.pdf

[DailyDose]

---

@JÞB wrote:

The TestStand application instance calls through the module adaptor to a proxy caller into the LabVIEW IDE or RTE. <gross oversimplification >   This does require that TestStand check the module protype at runtime and error when it has to protect itself.

The LabVIEW RTE does not typically use a proxy caller....[I once heard a evil spirit whisper that perhaps if you navigate to the 3rd or 4th sub basement......] don't look 👀

An exe can call into a ppl that exists outside the application.  Those ppls are often used as plug-ins by placing them in a plug-in folder.  You can even dynamically list the folder contents and select a dynamic process from the plug-in "Store."  Each ppl can always be updated and deployed and contains version information. 

That means that, in theory, you can easily create some sort of test configuration file driven application that sequences through actions to complete a process that may change dynamically between runs.  The developer hours needed for suchlike stuff is not really difficult at all.....until you need 1 more feature in your custom test executive.

---

You know, I walked away from my machine, got in my car, started driving home, then began to think to myself... "no... those test stations actually had LabVIEW development on them and we had to select in Test Stand the ability to open the Dev environment in order to run the VIs..."

Anyways, I've been using PPLs this whole time.  However, the PPLs were just to contain the parent and child classes of the instruments.  The plug-ins themselves would then dynamically load the classes based on instrumentation of the rack.  I was not aware the plugin also needed to be a PPL. 

I could have sworn, back in 2013, a guy I used to work with created a modular test environment that simply just loaded the VIs themselves and into the subpanels.  Please tell me I'm not crazy and that was a thing once upon a time.  

[cordm]

The error message is actually helpful in this case: "This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate."

The Express VI has sub VIs that are missing. Try to replace the Express VI with a hand made timer.

You can call a VI in an executable without the dev environment. It has to have the compiled code in the VI, but LabVIEW will tell you if it is missing.

[Yamaeda]

The run time engine can't access compiled cache, so it you're using Separate code it won't work. Either do a Code Export or fix that VI setting (though it's better to have it separated normally)