For me, the solution, was not to use *.llb in real-time targets. PXI or VxWorks.
Not only main .vi is important. Every dependence on RT Target must not reside on .llb.
I considered that, but it was too big a change -- and we'd have to change another product that shares many VIs with this, and confuse customers who upgrade..... the price was too big for improving the interface of two VIs. So I just went back to the old interface.
So my solution was basically to give up what I wanted to do and do it in a less optimal way.
Of course, the bug may bite us again sometime....
I am a beginner real-time programmer, so this is really frustrating for me to get no broken arrow, and then get such a generic error upon deploying. At least it told me what vi had the problem - Main :(. I was making a huge change to different hardware, so KUDOS to everyone who told me it might have to do with typedefs. I removed the one new .ctl that I made during this change, and voila! it deploys! I am working in Labview 2012SP1 with a 9076 in hybrid mode. (Restarting the controller and the computer did not work).
There has been a Corrective Action Report (CAR) filed on this error since April 2012.
R&D is investigating the error and ways they can produce error messages which are more indicative of the actual problem, rather than the current non-descriptive one.
Thank you for noting your experiences with the error.
I've made a note of this forum in the report for R&D. I'm sure they'll find it useful.
Any news on this? April 2012 is about a year and a half ago. Is there some webpage where we can check the status of this CAR? Does it have an identifying number?
FYI for CAR. Ran into this error again a month or so later than my post above. No broken arrow, just .vi loaded with errors on the target and was closed. The vi it would stop deployment at was different all the time, but always Main or vis containing SoftMotion. What I did to cause this was I converted my Express SoftMotion line vis to subvis and saved the subvi only. Also I created two custom icons for the vi that contains these subvis. I have done this before with no issues. However, this time it caused "external components" of nimc library vis to change on disk ie. WaitUntilDone, Contour (not sure why), and this request to save comes up every time I deploy or close my project whether I save or not. Repairing, uninstalling, reinstalling SoftMotion on host and cRIO did not work. Disabling SoftMotion vis did not work. Re-inserting them all as express vis did not work. Last working copy without the SoftMotion subvi did not deploy. Reformatting and reinstalling software to cRIO did not work. I had to upgrade to 2013 anyway, so I did this to solve my problem. Unfortunately, I couldn't spend longer to figure out what was going on. I am thinking replacing just the nimc library may have worked as well.
This is a bit of an old thread but I think I may have found a workaround for:
"blahblahblah.vi loaded with errors on the target and was closed"
I recently experienced the same issue on a PXIe-8115 controller running LVRT 2013.
Nearly the same type of trigger and symptoms as everybody else who posted.
Multiple deployment attempts with various levels of my project open yielded a consistent deployment error but with different vis being identified based on what code happend to be open at the time.
I tried unsuccessfully everything suggested above to no avail.
What did clear the error was deleting the repository where LV stores the compiled target specific code:
Once this file was deleted and the project files reopened, LabVIEW prompted me about a whole host of warnings regarding vi's being loaded from different paths (lots of stuff from vi.lib), but the entire project once again deployed without error.
By virtue of the fact that all of the compiled code was deleted, LV was forced to compile all code and create a new repository file.
I've got a new manifestation of this problem.
I've got 2 Compact RIO's running the same code (just with different configuration files). If I deploy the code to one CRIO, and then try and deploy it to the other CRIO I'll get "xxx.vi loaded with errors on the target and was closed" everytime, with xxx being the name of ONE of the sub.vis. The sub vi that fails frequently changes!
If I then try and deploy to the first CRIO, the code will also fail the same way. I can sometimes fix it by making dummy changes to each of the failing sub-vi's and saving them, but I have to do this to a long series of them to get it to work.
I can deploy and run each of the sub-vi's that fail individually, and they alway work. The error only occurs on the main app.
Deleting the repository as described above seems to fix the problem. Then I can deploy to one or the other CRIO, but it will break again if a try and deploy to the other one.
I DON'T want to separate this into two projects and maintain two sets of code, one for each CRIO, and try to keep the sync'd. But that is the way it looks like I'll have to go.
I've worked with this code for several years, and never saw this problem until I added a second CRIO recently.
I had the same error when moving my LabVIEW 14 code from OSX to myRIO.
I had a class that was causing the problem, I tried everything I could think about (remove var in the cluster of class private data, change class properties, etc.) with no success. To test my issue, I used a very simple VI which has the class constant connected to a class indicator, this would compile and deploy. As soon as I add a vi to for ex. read my object data member, the error occured, even if I don't do anything in this VI.
The last attempt was to rename my class via the right click menu, and ... it worked, the VI deployed successfully.
A renamed it a second time to give my class its original name, still working as if it never had any issue.