LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Replacing Source Distributions Called By Main Executable - sub Vi not executable

Solved!
Go to solution

Hello everybody,

 

I am working on a project using a main framework, which we distribute as an executable. This executable is being improved sporadically but the linkage to any sub VI's is always the same. I use the "Open VI Reference" (prepare for reentrant run) passing a static path to the VI (I made sure it's in the right place) and then the invoke node "Run VI" (Wait Until Done = False, Auto Dispose Ref = False). Depending on the application the sub VIs have minor differences. For example different HMI and a few more controls, but the overall function is similar. These VIs are implemented as source code distributions.
Now I have experienced problems, when I try to implement changes to the source code distribution, replacing it on the target system. I get the error, that the called sub vis aren't executable.

But if i rebuild the *.exe and the source code distributions at once (highlighting them in the build specification and selecting "build") then i don't get any errors at all.

 

This happened multiple times and I haven't been able to find any reason for that behaviour.

Thanks for all your help!

0 Kudos
Message 1 of 8
(1,380 Views)

The dynamic VIs need to be able to load all subVIs.

 

Your source should be included in the distribution, but vilib VIs are not. If these vilib VIs are not used in the exe, they won't be found. For me, this always was a problem for picture control VIs.

 

I suspect that if you rebuild the exe, (new) subVIs that are in the dynamic VI are probably also in the updated exe. But that's just a wild guess. Maybe because some code is shared between the exe and the dynamic VI.

 

You could test this. Is it really that building together fixes this, or is a recompile of the exe enough?

 

If you drop the dynamic VI on the exe, the exe will open it, and you used to get a slightly better error description if you press the broken arrow.

0 Kudos
Message 2 of 8
(1,325 Views)

Thank you for your reply!

 

I experienced my problem once again. I rebuilt my *.exe and LV could no longer successfully load the dynamic VIs from the source distribution (SD). I chose following settings concerning the vi.lib:

MikaG_0-1677146925119.png

As soon as i rebuilt one of the SD there was no problem with it. Dropping it on the block diagram of any diagram resultet in following warning:

MikaG_1-1677147052952.png

There was the same warning for the SD which didn't load correctly in the application.

 

Dropping the faulty VI on another block diagram revealed the following error:

MikaG_2-1677147472931.png

 

So it seems even though the source of the VI runs smoothly there's a problem as soon as I try to load the SD in a different VI/the *.exe. When loading the VI I received a few conflicts as the calling vi and the called VI both use some same VIs, but from different paths. Could this cause my problems and how would I go about fixing this?

0 Kudos
Message 3 of 8
(1,299 Views)

@MikaG wrote:

Could this cause my problems 


Yes, I think it could.

 

@MikaG wrote:

 and how would I go about fixing this?


Distributing source code to an exe has always been messy. You either get missing resources, conflicting resources, or both.

 

Most people 'fix' this (it's more a workaround) by using packed project libraries (PPLs). It's more work to setup, but the namespacing prevents a lot of problems.

0 Kudos
Message 4 of 8
(1,286 Views)

I'm not sure if I unsderstand how to implement the PPL. Is it possible to create that for the interchangeable modules?
And how can I maintain that code. Let's say we have two different modules with a similar top level VI (same connector pane, different FP elements) and the same called sub VIs.

Now i want to call that VI from my main application (*.exe), but also be able to replace the called PPL on the target system. I suspect that will result in similar problems as the ones I'm trying to solve.

 

0 Kudos
Message 5 of 8
(1,257 Views)
Solution
Accepted by topic author MikaG

Using PPLs can be a good way to achieve what you are after. I’ve done extensive work on a large research project developed a decade ago that is made up of over 50 individual projects. There is one top level executable and all the others are modules that compile into PPLs and have their top levels called dynamically from the exe and loaded into subpanels.

 

This works well as each sub-project can be modified and recompiled independently without ever stopping the executable. PPLs require an owning library so everything is namespaced naturally. Common VIs are compiled into each module and therefore namespaced into the PPL (with no conflicts). No module depends on another module. Even changing the common functions has no effect until the module is recompiled (bugs can be worked out in the development environment before building).

 

The executable can even load modules from the development code instead of the PPL for initial testing before building the PPL. It’s actually quite an elegant system if modularity is your goal.

 

The tricky part is getting the executable’s build settings right. I can never remember if you need 8.3 file naming or some of those other obscure settings checked. Fiddle with it until it works is the plan there.

_______________________________________________________________
"Computers are useless. They can only give you answers." - Pablo Picasso
Message 6 of 8
(1,242 Views)

@MikaG wrote:

I'm not sure if I unsderstand how to implement the PPL. Is it possible to create that for the interchangeable modules?
And how can I maintain that code. Let's say we have two different modules with a similar top level VI (same connector pane, different FP elements) and the same called sub VIs.

Now i want to call that VI from my main application (*.exe), but also be able to replace the called PPL on the target system. I suspect that will result in similar problems as the ones I'm trying to solve.

 


The PPL will always contain all code it needs. The VIs are namespaced, so shouldn't conflict with VIs in your exe that have the same name.

 

The purpose of PPLs is exchangeable modules.

 

Unless the code is in a class, you should be able to load and unload the PPL. IIRC, classes are hard to unload from memory.

 

What is the 'target system'?

 

Message 7 of 8
(1,237 Views)

Thank you all for your responses and helpful tips! I finally got around to testing this solution and so far everything's working well.

I had a few problems calling VIs in the packed project library (PPL) at first, but found this helpful entry right here: Call VI in PPL 

 

I need to implement some mechanism to select the correct sub-vi from the list of existing VIs, but that wont be a challenge.

 

Once again, thank you for your great input!

 

0 Kudos
Message 8 of 8
(1,138 Views)