02-26-2010 08:45 AM
I will give this a shot the next time it happens.
Thanks,
Chris
07-13-2010 07:46 AM
Thank you, Marti! That worked well for me, and saved me a few hours of work.
Brad
08-09-2011 02:39 PM
Thanks Marti!
I had the same issue in Labview 2010, and copying the file from the recovered files directory fixed it.
Whew. Must remember to save more often.
12-01-2011 04:58 PM
But what are the causes of this. I have a VI that is repeatably doing it. I have tried copying and pasting the block diagram and that fixes the problem for a while but it always comes back!!
12-07-2011 04:47 AM
Same problem. Lost 2 hours of work after opening the crashed VI. Why don't they find a proper solution???
12-26-2011 12:18 AM
Hey
Even i faced the same problem with 2010 version , where after an internal crash i could neither save nor copy (select all) to another file.But then in my case i felt it was an express VI that caused the problem . So i just removed nly those three express VI's present in the whole program,then gav (select all-copy -newfile)everything went perfect.This actually saved me the effort of coding it all again.I lator pasted those VI's separately into the new file.Hope this might be useful to someone
Namitha
09-11-2012 01:31 AM
On LabVIEW 2011, I tried removing the express VIs as suggested. It allowed me to save, without having to copy-paste to a new file. It points towards an issue with the recovery of express VIs.In my case, I were using a DAQ Assistant express VI within a loop.
02-13-2014 01:11 PM
Yes!!!!
I had one express vi in my code (time delay - very uncommon, I'm sure not many are using it). I deleted it from the recovered block diagram and WHAMMO I can save again! Thanks for the tip!
BTW:
LV2012
Win7(x64) Build 7601 service pack 1
10-03-2014 04:33 AM
I had the same error, luckily I tried to save straight after adding a display message to user express VI, I just removed it and the error went away.
01-07-2015 05:51 AM
For information:
I just encountered this in LV2011.
I'd restored a paused Virtual environment, and the path to a few VIs was actually through a shared pipe to the host drive. Upon restoring the virtualised OS the shared resource wasn't available, and hence to LabVIEW it had appeared that suddenly these VIs were missing. Their entire file path was unavailable.
Upon restoring the path to their location they recovered without a problem.