Persistent Dependency Error

[JeffinCA]

  I have an app with several subVIs.  One of them was originally named "Check System Power.vi", but I renamed it by saving it as "Check System Voltages.vi" nearly two weeks ago.  Because the parent VI was open, it updated the dependency and I loaded, and even compiled, the program several times following that rename.

  Last week, and again today, the process of opening the parent VI paused and I was prompted to find "Check System Power.vi".  The first time, I cancelled the prompt, found the resulting errors and Replaced them with "Check System Voltages.vi".  Everything worked fine until today.  Today, I was again prompted to find the non-existent file "Check System Power.vi"; I pointed specifically to "Check System Voltages.vi", the replacement was incorporated, but I got a warning.

  I am using LabVIEW 2010.  I would like to know if this bug is known and what I can do to get rid of it.  I do have LV 2011, but I am hesitant to install it until I get this project completed because I don't want to create any new problems.

  If this does turn out to be a known bug, was it fixed in LV 2011?  Is there are related bug where previous definitions created in MAX are loaded instead of the most recent?

Thanks in advance,

Jeff

[RavensFan]

Did you save the top level VI after you found the new subVI?

If you saved the higher level VI, it should continue to find the new subVI everytime you open it unless you happen to move/rename the subVI again.  Is your L:\ drive a network drive?  Any chance something is happening behind the scenes like someone putting an older version of the subVI back, or your IT dept, restoring files from a backup VI.

[JeffinCA]

  I saved the top level VI several times over the last couple weeks and also opened the top level VI several times over the same period.  The dependency failure has happened twice in that period (6 days ago and today), both times with the same file.

  L: is a partition on a RAID 0 setup on a private computer (no Intranet and I am the only programmer).

  The working directory's path has been unchanged since Aug. 24th.  I make backups by copying the entire directory and renaming it.

  I am using LabVIEW 2010 on a Windows 7 Pro system.

Jeff

[RavensFan]

Are you making backups by copying the whole directory and giving that a new name so that you continue to work in the original name directory?

Or do you begin working in the directory with the new name?

[JeffinCA]

  As I said, the working directory's path has been unchanged since Aug. 24th.  I copy the entire directory to a new name, but continue working in the original path.

Jeff

[RavensFan]

True, you did say that.

You mentioned in your first post something about "previous definitions in MAX".  Why do you think MAX would be involved in this problem?

I haven't heard of any problems with the dependencies in either LV2010 or 2011.  I'm stumped.

[JeffinCA]

  I do not think that MAX is associated with the current problem.

  In addition to the problem I have described in this thread, I also have a problem where compiled software that accesses a DAQ has occasional problems with the amplitude of the waveform that has been acquired (and the hardware isn't at fault), so I added it in the hopes that anyone who had knowledge of this Dependency bug would also be aware of a bug in MAX and be able to tell me how to work around it.

Jeff

[RavensFan]

The only thing I can think to add is to be careful not to open both the current project and the backup copy at the same time, especially if you open VI's outside of the project environment as you would cause files to link to one already in memory rather than the ones in the project directory.  You probably already know that, but just in case.

[JeffinCA]

  I learned not to do that during my classes, along with the problem of moving files to a different path.

Jeff