LabVIEW Project fails to auto save

[Skip]

When using LabVIEW 8.5.1, I get the error message: Failed to auto save "my project name.lvproj" for recovery.

[Justin Goeres]

QUOTE (Skip @ May 27 2008, 05:23 AM)

When using LabVIEW 8.5.1, I get the error message: Failed to auto save "my project name.lvproj" for recovery.

Under any particular circumstances? (Is your disk full? Is your project on a network drive? Does it happen all the time on all projects, or just once in a while on certain projects? What are you doing when it happens? etc.)

What you're describing has never happened to me.

[David Wisti]

I'm getting the same error message here too. Seems to happen one time per project. The error does not occur right way. If the project has not been saved and there is a * in the title and I run a VI, the error message will pop up.

QUOTE (Skip @ May 27 2008, 07:23 AM)

When using LabVIEW 8.5.1, I get the error message: Failed to auto save "my project name.lvproj" for recovery.

[Jeff B]

For anyone who's seeing this problem, what can you tell me about your project? What kinds of things are in your project when you see this? Are you using other targets (RT, FPGA, etc)? Is it a particularly large project? Can you reproduce it starting from an empty project? Good observations David, I'll expand slightly on your steps that might help to reproduce the issue...

1. Close and re-launch LabVIEW.

2. Open your project and make some change to it.

3. Run any VI (we trigger an autosave before VI execution).

As David said, if you see this dialog once, you will not see it again until you close and re-launch LabVIEW, making the first step being necessary.

If anyone can reproduce this I'd like to know how - preferably in a way that doesn't require hardware, but if that's required to see the problem, that's fine too. Be sure to let me know what add-on module(s) you have installed (like RT, FPGA, etc).

Thanks,

Jeff

[David Wisti]

My projects are quite large, 1000+ VIs. RT and FPGA targets exist in these projects. There is another unrelated issue with some of my projects. When I open my larger projects, they always open with unsaved changes even if you explicitly save the project before closing.

[Jeff B]

I don't expect these issues are related, but are you able to answer any of the other questions I posed? Particularly, have you attempted to reproduce it in a new project? What about a new project with a target added? What about once you've saved the project and then make more modifications to it? I understand that troubleshooting this probably isn't that high a priority for you, but as I haven't been able to reproduce it, any information you're able to provide is greatly appreciated.

[Justin Goeres]

QUOTE (David Wisti @ May 27 2008, 07:39 AM)

When I open my larger projects, they always open with unsaved changes even if you explicitly save the project before closing.

I don't mean to threadjack, but there are some known situations that can cause that to happen. The most common is that if you have any auto-populating folders in your project, the act of opening the project file causes LabVIEW to refresh those folders and it somehow always concludes that something has changed. I don't remember any of the other causes (because the auto-pop folders one is by far the most common for me), but my understanding is that the issue is annoying but harmless, and NI is generally aware of it.

[David Wisti]

Jeff,

I was unable to reproduce it in a new project. I tried adding in both a RT targets and a FPGA targets. I saved the project and then make more modifications to it. Also, few combinations of such and still no error message. I wonder if it only happens to projects converted from 8.5 to 8.5.1.

On the projects that I do see the error message, the error message will appear without doing anything, it just pop-up by itself. This error message was noticed immediately after I upgraded to 8.5.1 on the first project I opened.

If I find out anymore information, I will post it here.

David

QUOTE (Jeff B @ May 27 2008, 10:01 AM)

I don't expect these issues are related, but are you able to answer any of the other questions I posed? Particularly, have you attempted to reproduce it in a new project? What about a new project with a target added? What about once you've saved the project and then make more modifications to it? I understand that troubleshooting this probably isn't that high a priority for you, but as I haven't been able to reproduce it, any information you're able to provide is greatly appreciated.

[silmaril]

QUOTE (Jeff B @ May 27 2008, 04:01 PM)

I understand that troubleshooting this probably isn't that high a priority for you, but as I haven't been able to reproduce it, any information you're able to provide is greatly appreciated.

This is exactly my problem. Since I don't have any time to dig into this any deeper, I simply disabled automatic saving in the options dialog to get rid of the message.

I got the same message frequently in my current project - not only after restarting LV, not on every start of a VI, but several times a day from time to time.

Maybe I can throw in some facts about the project in question:

• It was created by copying and renaming another project.
  
• It only has one target "My Computer".
  
• It currently consists of 300+ VIs and CTLs.
  
• It uses several LVLIBs.
  
• It does not contain LVCLASSes.
  
• It does not contain auto-populating folders.
  
• All files including the project file are under Source Control, using the Perforce Command Line client.
  
• There are some custom Conditional Disable Symbols on the "My Computer" level.
  

If it helps, I could send you the project file without the VIs via E-Mail. Please let me know if you think this might help.

If NI R&D is not able to track this down, I have one wish for the next version: Please make this error message more verbose! Right now, the only information it gives is that something went wrong. If the message contained more background information about the "local circumstances" inside the code, you would get much more helpful user reports on this.

[Bob Schor]

I'm having the same symptom, but have some further clues on its origin. I've been developing a real-time data acquisition project using Project in LabVIEW 8.5. I'm still at an early stage of development, so my code is not yet "full-blown". My basic model uses state machines, both on the Host (PC) and on the Remote (PXI, eventually), with communication between them using Shared Variables. Because I'm trying to develop a "generic" code base that will be used for various lab projects, I have two Host VIs, a top-level VI that mainly handles the real-time communication with the Remote, and a called Host VI that contains the specific Host code for the particular experiment (i.e. it has a user-specified Front Panel, displays, etc.). Top-level Host calls "user-specific Host", which, in turn, starts the Remote VI.

At the present time, all three VIs (and their dependencies) run on the PC -- I have not yet "dragged" the Remote folder to my RT Target (I'm simulating data acquisition for now, just trying to get the basic architecture worked out). When I run Host VI, it invokes "User-Host" VI, which starts "Remote VI", and everything works fine.

Over the weekend, I upgraded all(!) of my three development PCs to LabVIEW 8.5.1. The LabVIEW code that I've been developing hasn't changed (I know, because it is under Source Control, and I've checked the revision level). The difference is that now I'm getting the error message described here! One scenario that provokes the message is the following: (1) Start LabVIEW 8.5.1 [i'm going to do this in parallel with writing this message, so bear with me ...]. (2) Open the Project, and load the Host VI. (3) Run the Host VI. What I notice is that I see it "deploying" its shared variables, but then I get a dialog box with the text Failed to auto-save "PROJECT S-Lab.lvproj" for recovery. On at least one machine (the present one) that I tried this, after clicking "OK", the code seemed to run all right.

On a hunch, I tried disabling part of the code in my top-level Host VI, specifically the call to the "User-Host" VI that also calls the Remote VI. There was still code left that attempted to initialize the Shared Variables, and I again saw a dialog box that I think talked about Deploying, and I again got the "Failed to auto-save" message. So I'm going to guess that this particular "feature" (which, to re-emphasize, does NOT appear in LabVIEW 8.5, but DOES appear in LabVIEW 8.5.1) may have to do specifically with Shared Variables.

Oops, might not be that simple! I just disabled more of my Top Level Host VI, including all of its calls to VIs using the Shared Variables. It now does almost nothing (and, specifically, I don't see dialog boxes talking about deploying things), but I now immediately get the Failed to auto-save message!

Well, it's getting late, and I want to post this. However, I may try tomorrow to make a copy of this Project, throw out large sections of it, and see if I can't get down to a "simple" system that exhibits this particular flaw. If so, I'll post it (or pictures of it) and we can see if NI can figure this out. I suppose I could also try to "downgrade" one of my PCs back to LabVIEW 8.5 and see if the problem goes away ...

Bob Schor

[Jeff B]

Thank you for the updated info, I apologize I somehow missed the replies at the end of May.

This is now a known issue, and is documented internally with ID# 115766. I have already made changes to improve the error reporting in a future version of LabVIEW.

silmaril - if you still have the LVPROJ file, open it in a text editor like notepad. See if one of the first few lines contains the text "varPersistentID". If so, there's no need to send it in. If you do not see this text in your project, please let me know. Be careful to not save or modify the project in the text editor.

Bob - I think you've touched on the crux of the issue here, and that is this issue's connection with shared variables.

See here for more info:

http://forums.ni.com/ni/board/message?boar...hread.id=334074

[silmaril]

QUOTE (Jeff B @ Jul 29 2008, 03:35 PM)

This is now a known issue, and is documented internally with ID# 115766. I have already made changes to improve the error reporting in a future version of LabVIEW.

Great! Thank you! :thumbup:

QUOTE (Jeff B @ Jul 29 2008, 03:35 PM)

silmaril - if you still have the LVPROJ file, open it in a text editor like notepad. See if one of the first few lines contains the text "varPersistentID". If so, there's no need to send it in. If you do not see this text in your project, please let me know. Be careful to not save or modify the project in the text editor.

I'm still working on this project (and will continue to do so for the next months).

My project file contains two varPersistentID-properties. Is this the way it shold be, or could that be part of the problem?

I don't use any shared variables in this project. Maybe deleting those varPersistentID-Tags could solve the problem for me?

What do those tags do anyway?

[Jeff B]

To be perfectly honest, I'm not that familiar with the inner workings of the shared variable, but as I was investigating this issue, I learned a little about these entries. Generally speaking, the purpose of the persistent IDs is so that variables can still identify themselves as being the "same variable" even after being renamed. It surprises me that you have no variables in your project and yet these varPersistentID entries still appear. Are you sure some library in your project doesn't have any variables that you may have forgotten about or just not be using? I don't know what consequences removing them from the project could have. It could be very bad, as in your project may no longer load. If you made a backup you could try it, it probably wouldn't have any negative consequences and would probably fix the autosave issue, but I'd hesitate to tell you it's 100% safe to save the project that way and keep working.

I dont know how big your project is, but if it's small enough or otherwise organized simply enough such that you could re-create the project by re-adding its contents, particularly if you really don't have any variables in the project, that is likely to fix the problem as well, and in a safer (but more potentially error-prone and time-consuming way).

[silmaril]

There might have been some shared variables in this project once, but they were replaced by a self-implemented TCP/IP-communication. The mentioned tags are propably left-overs from this time.

The Project ist quite large (over 700 files and growing). It's completely under source code control, so I can access older versions any time.

I deleted those two lines yesterday in the morning and worked all day with the project without any problems.

If I should really run into any problems, I can still copy the deleted tags from an older version. That's one of the really nice things about using XML