What is the root cause of "...loaded with errors on the target and was closed" error when deploying VIs to cRIO

[Petru_Tarabuta]

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!

[raphschru]

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.

[Quiztus2]

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 🙂

[raphschru]

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.

[Petru_Tarabuta]

Hi Raphaël and Quiztus,

Thanks for your very useful suggestions. It's heartening to see that others have experienced the same frustrations, and that there are a few possible workarounds. Before I posted the question I too felt the "I am at my wits end" feeling expressed by BBSim in the Deploying to cRIO is effectively impossible. thread.

It seems that the possible workarounds are:

1. Unticking the "Separate compiled code from source file" setting for every file in the code base.
2. Modify the LabVIEW.ini file to add the following token: useCacheForDeployment=False.
3. Inspecting the cRIO Error Logs in search of any relevant information.
4. Use projects that contain a single target.

I haven't tried any of these workarounds yet, but I will, and will report back with any findings.

A few pieces of information that I didn't mention in my initial post but which could be very relevant to this issue:

• I typically develop the code on a laptop whose configuration is Windows 11 running LabVIEW 2024 Q3 (24.3.2f2) 64-bit. Then I use git to commit and push my changes to a central git repository. Then I use git to pull the changes onto a desktop PC with the same configuration: Windows 11 running LabVIEW 2024 Q3 (24.3.2f2) 64-bit. I then test the code from the desktop PC which is connected to the cRIO-9045. I sometimes make edits from the desktop PC, commit and push back into git, then continue editing on the laptop. In short, the source code is edited on two machines.
• All VIs in the codebase currently have the "Separate compiled code from source file" setting enabled.
• The several projects I have been using for deployment so far all contained two or more cRIO targets, and most of them contained code  under the My Computer target too. I had not been aware that this might be an issue, so thanks Raphaël for mentioning this and pointing me to the extremely useful HSE Wiki.
• The HSE Wiki section on the "loaded with errors on the target and was closed" issue contains a screenshot in which the error message points to the native General Error Handler Core CORE.vi. I am virtually certain that I experienced the exact same error in the last two to three weeks, meaning that it was exactly the General Error Handler Core CORE.vi VI that the deployment errored at.

[Petru_Tarabuta]

A progress update. What I have done so far is:

1. This morning, prior to posting the initial post above, I had closed LabVIEW on the desktop PC connected to the cRIO.
2. 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.
3. 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!