LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug: Deploying SubVI with subpanel breaks deploy to RT but does not break caller VI

Hello Everyone,

I have stumbled upon a very annoying behaviour: 

 

When a VI with subpanel (or subpanel ref) gets into the dependecies of the top level vi an thus needs to be deployed, it does not break the top level vi itself but the deployment of it fails. Labview only tells you that you cannot deploy a VI with subpanel on it but it does not tell you which VI is causing all of this (or mistakenly points to the top level VI). In our case it was a VI in a class and was very tedious to find because labview does not tell you anything and is very tricky to find when ~3000VI needs to be deployed. I expect one of the following behaviour: Break the top level VI or at least tell which vi is causing the deployment to fail.

LV version: 2020f2
RT: IC-3172 fw 8.0.0f1

0 Kudos
Message 1 of 3
(1,183 Views)

Hi!
Have you tried to mass compile your project?

0 Kudos
Message 2 of 3
(887 Views)

I have worked around the issue and created a VI which searches for VIs in memory with subpanel/subpanel ref on it and then tries to find the call chain to the top level vi. This filters out most of the direct dependencies but there is the case of the VIs which are not called directly but included in the dependencies nonetheless. Such Vis are the dynamic dispatch methods which are loaded into memory even if they are not called and thus LV tries to deploy them to the target for some mystic reason and obviously fails. A few condition disable structure solves the problem but it is not an elegant solution by far. One could argue that why isn't the UI methods are in a separate library/class and they would be right but for the time being I am stuck with this codebase. Mass compile would not solve this problem and for why it occasionally succeeds is also mystic to me.

0 Kudos
Message 3 of 3
(837 Views)