02-06-2021 04:01 AM
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
06-18-2021 01:21 PM
Hi!
Have you tried to mass compile your project?
06-22-2021 01:16 AM - edited 06-22-2021 01:17 AM
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.