From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Uncalled VI within a Library that uses sub panels is preventing deployment to cRIO

Solved!
Go to solution

Hi, 

 

Ive had to upgrade my LabVIEW from 2018 to 2020 and ive encountered an issue with a Library. The library is for a Hardware Abstraction Layer (HAL) and the subpanels are only called on a Windows PC to configure DAQmx tasks. 

 

Before upgrading to LV 2020 I was able to deploy the project to the cRIO just fine and run the Embedded UI project. Now after upgrading to LV 2020 I am presented with the attached error when deploying. I can build the code as an RT EXE and run that just fine but this is a very slow way to develop a project.

 

Any advise would be much appreciated!

 

Note - I am curevtly uninstalling all NI software on my laptop and going to do a fresh install as I have seen issues with me LV when trying to save the project. 

 

LV error.PNG

0 Kudos
Message 1 of 5
(959 Views)

I'm a little confused.  You said you are implementing sub-Panels on the Host PC, which makes sense since the Host is where the User Interface (with Front Panel interactions, sub-Panels, etc. are "hosted"), so the code should not be placed on the cRIO (since it's not being run there).

 

I've never tried to implement a sub-Panel on a RIO system.  I could imagine (but haven't tested it) that including a sub-Panel in a library running on the RIO, even if never called, might result in a Deployment error -- possibly this "slipped through the cracks" and was cleaned up in LabVIEW 2020.

 

Can you simply remove the sub-Panel code from the library running on the cRIO?  If you don't use it there, it shouldn't hurt not to try to deploy it there ...

 

Bob Schor

0 Kudos
Message 2 of 5
(935 Views)

Sorry ill try to be a little clearer, So in my architecture I uses a HAL to allow me to configure DAQ on the Windows PC and write that to a class. I then send this class to the cRIO over network streams via XML to allow different hardware configurations to be sent to the cRIO without changing code. 

 

Unfortunately I feel to may have to rewrite the VIs that use sub panels. My initial thoughts would be to put the entire vi in a Conditional Disable structure but I don't think this would work as the terminal connections are still present.

 

I'm trying to find a solution that doesn't require me to rewrite the VIs that use sub panels as this didn't used to be an issue on LV 2018

0 Kudos
Message 3 of 5
(916 Views)
Solution
Accepted by Martin20896

So I've been in a support ticket with NI and have found that if you have a subpanel within a class that can be dynamically dispatched to within the class but are not currently calling that VI you get different behaviours within LV 2018 and LV 2020. 

 

In LV 2018 you would be able to deploy but with LV 2020 you are presented with the error I have been seeing. In my eyes this should be a bug as the functionality in 2020 is more restrictive even though I am not calling the sub panel VIs I am unable to run it in source but I can as an EXE. 

 

In the time been I have simply replaced the sub panels with popups. 

0 Kudos
Message 4 of 5
(861 Views)

But for the exe you build it with the option to remove unused library methods and such? So technically the exe does not contain those VIs and hence it can be deployed.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 5
(846 Views)