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!