LabVIEW
What is the root cause of "...loaded with errors on the target and was closed" error when deploying VIs to cRIO
Hi,
I am developing a cRIO application.
My setup is:
Development machine = Windows 11 PC running LabVIEW 2024 Q3 (24.3.2f2) 64-bit
Target = cRIO-9045
I am sometimes getting an error that prevents me from running code on the cRIO. The error message is "Deploying <fully qualified VI name here> loaded with errors on the target and was closed.", as can be seen below.
The VI named in the error message is a simple VI that has not been modified in weeks, and has a solid run arrow. So why this error appears is a mystery, and as far as I can tell is a LabVIEW bug.
I encountered the error message above three times in the last week. Each time, performing a mass compile of the project folder resolved the issue. I was then able to deploy the exact same top-level VI (no code changes what-so-ever) to the cRIO. Please note that other times the deployment worked fine.
Today the error message appeared again. I mass compiled the project folder, but this time this did not fix the issue. Instead, I am now getting a similar, but slightly different error message, as seen below.
As can be seen, it is the same type of error message. The VI in question has changed though, from Remove Confirmed Elements.vi, which is a member of a certain lvclass which is a member of a certain lvlib, to DAQ Configure.vi, which is a member of a different lvclass inside a different lvlib.
In short, the full VI names are something like: L1.lvlib:C1.lvclass:Remove Confirmed Elements.vi and L2.lvlib:C2.lvclass:DAQ Configure.vi.
As of right now I am unable to deploy the cRIO VI and test my code.
Questions
- Does anyone know the root cause of the "... loaded with errors on the target and was closed" error?
- Why does this error sometimes appear, why is it sometimes cleared by mass compile, and sometimes isn't?
- To me this seems like a LabVIEW bug. Does anyone else think the same? Does anyone know whether this bug is already recorded as a CAR (Corrective Action Request)?
Finally, I just want to say that it is so frustrating dealing with situations like this. I completely resonate with the point Darren made in his excellent LUDICROUS ways to Fix Broken LabVIEW Code which is that whenever NI runs surveys such as "What is the next feature you would like to see implemented in LabVIEW?" he is always forced to select "Other" and type "editor and run-time performance and stability improvements" (see between minute 04:00 and 05:00).
If anyone from NI reads this: NI, many of us have built a career out of using your tools. Please invest time and effort into improving the reliability of the LabVIEW development environment! It is not acceptable to have the code failing to build and/or failing to deploy for no apparent reason. The tooling needs to be rock-solid. This is a must, not a luxury. Don't force us to transition to other toolchains/other vendors, which, if pushed enough, we will.
Many thanks for any help!
Hi Petru,
Here I suggested an idea that somehow diminished the issue (not solved):
Deploying to cRIO is effectively impossible.
I agree that we should not have to do that and NI / Emerson should invest more resources in correcting bugs.
I sometimes find bugs like this and decide to spend some time to report it to NI while attaching a sample project that reproduces the issue.
I feel like this is the right thing to do to make the bug corrected, but at the same time it is quite frustrating that there is barely any feedback on whether it is being taken into account or not by the NI R&D.
Regards,
Raphaël.
I feel you. Dunno if this was solved in 24 Q3, but for 23 I had to add this .ini entry:
Modify the LabVIEW.ini file to add the following token: useCacheForDeployment=False. Then, restart LabVIEW
And for logs you could check https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LpCSAU&l=de-DE
But don't expect too much from that.
Good luck 🙂
I also remember @joerg.hampel has an entry for this issue in his wiki:
https://dokuwiki.hampel-soft.com/kb/ni-rt/deployment#unclear_error_messages
The suggested solution is to only have 1 target per project.
A progress update. What I have done so far is:
- This morning, prior to posting the initial post above, I had closed LabVIEW on the desktop PC connected to the cRIO.
- This evening, before testing any of the workarounds above, I first wanted to check that I am still getting the same issue as in the morning.
- I launched LabVIEW, opened the project I was using for testing, opened the top-level VI under my cRIO target and pressed Ctrl + R. The deployment failed, but this time with a different message, as seen below. Murphy is surely having a good laugh! Note that now the error message occurs at the very end of the deployment and states "Deployment completed with errors" instead of occurring in the middle of the deployment and stating "Deploying <fully qualified VI name here> loaded with errors on the target and was closed.".
4. I applied useCacheForDeployment=False to the LabVIEW.ini file and restarted LabVIEW.
5. Opened the project, opened the top-level VI and pressed Ctrl + R. The deployment failed again in the exact same way as in step 3 above.
6. Created a new project, added a single cRIO target to it, and added the top-level VI to the cRIO target (all dependent lvlibs and lvclasses were listed under the Dependencies section). Ran the top-level VI. The deployment failed again in the exact same way as in step 3 above. However, this time I noticed some bold text briefly appearing somewhere in the middle of the deployment screen.
7. Ran the VI again, got the same error. Then scrolled back up to see the bold text, which can be seen below.
The bold text referred to a CTL file inside an lvlib (a DQMH module) whose Main VI did contain two Network-Published Shared Variables. All instances of reading/writing to these NPSV's had already been disabled a few weeks ago (a Diagram Disable Structure had been drawn around them). Prompted by the error message I removed the two NPSV's from the Main VI, and from the lvlib.
8. Ran the top-level VI again. The deployment completed and the VI ran successfully.
9. Let the VI run for a few minutes to convince myself that it was running fine. It was.
10. Closed the project that contained a single cRIO target, and opened the main project that contains code under "My Computer" as well as 7 cRIO targets.
11. Opened the same top-level VI from under the appropriate cRIO target. Ran the VI. The deployment completed and the VI ran successfully again.
This is all the testing I have done so far. What stands out for me is:
- The initial error message (first screenshot) was different! All that has happened between getting the "Deploying <fully qualified VI name here> loaded with errors on the target and was closed." error in the morning and getting the "Deployment completed with errors" error in the evening was 1. Closing down LabVIEW; 2. Posting on the NI forums. 3. Time elapsed (morning versus evening). Clearly one of these - likely posting on the forums - is a solution! Jokes aside, this is another aspect that makes developing for CompactRIO so frustrating sometimes. The seemingly random and intermittent nature of the issues.
- The VI had been deployed and ran successfully on many occasions in the last few weeks, even though those two disabled NPSV's were referenced inside the Main VI of one of the DQMH modules. I don't understand how those NPSV's started causing the error message seen in the screenshot, when the code was not changed.
- Deploying from the main project that contains many targets worked. This has worked for me on many occasions in the last few weeks too. I had not been aware of the recommendation of "one target per project" until today. I will aim to stick to this recommendation going forward.
Because the error message was different from the very beginning of my testing this evening, I'm not sure whether anything written in this reply is relevant to the original post. I will continue keeping an eye on things and report here if the original error returns and/or I can fix it using one of the workarounds.
Thanks!
Hi Quiztus,
No, the Enable Embedded UI setting is turned off, as seen below.
In an ideal world I would like the Embedded UI to be enabled, such that I can use Value Change events (button presses) in the several tester VIs. But I can live without that setting.
A few weeks ago I enabled the Embedded UI setting, but soon I ran into "Deployment completed with errors" messages just like the one in the first screenshot of my last reply. So thanks for suggesting that that might be the problem with the screenshots from yesterday evening!
I created this post on the LabVIEW Embedded community addressing this issue on 20 November 2024 (two weeks ago). Sadly it has not received any replies yet. Since posting that message I reverted to having the Embedded UI disabled. A few days after posting that message I also realised that there is a setting named "Allow development for this target with embedded UI enabled" in the General page of the cRIO properties window.
This setting has always been turned off. I have been meaning to enable it and to tick the Enable Embedded UI setting in MAX, and see whether that solves the issue mentioned in the 20 November message.
What is interesting is that even though the "Allow development for this target with embedded UI enabled" was always disabled, I was able to successfully deploy and run small VIs that used buttons and Value Change events on those buttons. But I would get the "Deployment completed with errors" message whenever trying to run the main VI of the cRIO application.
On a separate note, after the update yesterday evening (my last reply above), today I successfully deployed and ran the main VI of the cRIO application at least 5 or 6 times. It always deployed successfully, it never failed. So it was a good day. I have started using a single cRIO target per project.
I think this non-deterministic behaviour can only be corrected by NI. You did a perfect job by documenting this, now it is NI's turn to hire a second developer for LabVIEW or let the one stop debugging BD zoom.
