11-02-2012 02:33 AM
Working around this issue I discovered that this error can be obtained changing tree hierarchies of typedefs, including classes, that are used on RT targets.
Botton nested typedefs do not refresh propertly the changes on the top elements and LV detects that compiled code is corrupted or something.
Asking for this issue to NI they said that there are a "investigation process" or something about the error. In 2014 will be review because ".vi loaded with errors on the target and was closed" error is not very descriptive.
I solved it changing labels in all the ascending typedef tree and resaving them...
Maybe solution described by MGiacomet or this solution are usefull, but this is not serious.
Things to think because it seems that LV is not as robust as it looks.
11-02-2012 07:20 AM
More news...
Today the problem surfaced again... And deploying to another unit isn't fixing it anymore!
This is a serious BUG and NI is being nonchalant about it. There isn't even a CAR (Corrective Action Request) created and this is being left to the Customers to figure it out by trial-and-error. Imagine if this were to stop a controller at a factory???
Yes, it appears that LV has problems with classes (my code too has classes) and there are quite a few other times when changes in classes don't get propagated properly.
11-02-2012 09:09 AM
Edupo is in the right track...
It has to do with typedefs not propagating. I had a class and a member of it wouldn't load when used on the "offending" project. On another project the same class would work fine.
The "solution" was to delete every instance of the class' typedef and reinsert them. Eventually, it started working again...
Again, this is a BAD BUG that may cause someone to lose time/money.
Please give kudos to Edupo's message, so it gets NI's attention.
11-05-2012 01:45 AM
"Again, this is a BAD BUG that may cause someone to lose time/money." You are right!
This bug is dangerous because at very beigining of developing process is not shown... But when we have to review code or modifiying specifications can be very anoying... And in a really big project...
I lose a lot of time (more than one day) dealing with this issue. Now i'm working with SVN server and Tortoise to get all my code safe. It's quite good. (I started using it because of this problem!!)
Thanks MGiacomet for your support!
Please some of NI Team can feedback us?
01-14-2013 12:53 PM
Thank you for this post!
I had a similar problem and I ran into two instances of it which were very hard to isolate. I think both are related to the problem or LLBs.
I am using LV2011 on cRIO 9012.
I have had this error message with typedefs and globals in llb. Typically it looks like changes not propigating.
Most recently I have also had this problem with a sub vi. The problem was interesting for two reasons. I was debugging locally and was able to execute the function shown below on the PC with an error in the case/controlling enum. No broken arrow detected the error. Deploying the project caused the 'loaded with errors message...' I have removed all the suspect elements and left only the most basic elements of this function. Still would not deply but ran fine locally.
I noticed that the error existed by manually going through everything and corrected it. No change locally tried to deploy it and got the same error.When I opened the file on the target (as part of the project) I noticed the mismatch error was back -like the edit had never happened - I edited it again and again it failed.
I saw your post and removed the file from the llb and instantly the broken arrow appeared locally...I edited it again and it worked both locally and on the cRIO.
I have moved all typedefs and lib functions out of llb now and life is returning to normal.
Thanks for your post! Hope this helps highlight the problem
01-15-2013 11:33 AM - edited 01-15-2013 11:35 AM
"Please some of NI Team can feedback us?"
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.
Kind Regards,
Zach
01-17-2013 01:42 AM
Thanks Zach-H!
I learn to live with typedef structures problem.
I hope R&D can solve this issue as soon as posible.
To think about:
Memory is not cleaned when I close LabVIEW? (Is much more probable that mod's works when I restart windows!)
Changing typedef not update memory mapping of itself on RT?
I can only speculate about this with my knoledge.
Regards!
02-06-2013 08:08 AM
Hi Zach,
I too am having this problem. When a try to run my project on a RT device (in my case smart camera), The last line of the deployment says
"XXXX.vi loaded with errors on the target and was closed"
"Deployment completed with errors"
As one of the other post suggested, When I deploy to another RT device there are some new files that labview finds that are modified. After this if I deploy to the original device it works fine unit l the code is modified again.
From the earlier post it seems this related to typedef not updating properly. Is this correct? Does this mean I can remove my type definition (There is only 1 in my project) and the problem will go away?
I don't necessarily need a fix for the problem but I need to know what in my code is causing it so I can avoid it.
Thanks
Chris
04-18-2013 04:18 AM - edited 04-18-2013 04:21 AM
I just ran into this problem too. I think so. I AM using LV2011, LLBs and PXI and LVRT.
My application was running fine. I changed the interface of one function (adding a helper function). I did add a simple typedef (cluster of 9 integers. No classes, nesting.....)
Now I get this deployment error for the main VI. SubVIs deploy OK.
I disconnected from the typedef and removed it from the project.
Closed and restarted LabVIEW and rebooted the target.
Still have an error.
Anyone out there who can help me get around this? I'm pretty stuck. I can't use the suggestion to deploy to another target -- we only have one here. Closing LabVIEW asked me to save other files; I'd hoped this was doing the same as depoying to another target in that respect..
Batya
04-18-2013 04:22 AM
are you using Labview2011 with PXI and .llb extension archieves?
This combination didn't work. If you eliminate the library this error don't happen. I already talk with someone at NI about it, they told me that should be a bug at SW, but, anyone give me a reasonable answer.
I am. What do you mean by "eliminate the library"?