02-25-2012 06:28 PM
I'm using LV 2011 in VirtualBox with Win7-32bit guest. The host is Win7-64bit.
In the past I've always kept my project work within each VirtualBox environment, but this time I'm keeping my XControl project in a shared folder on the host and accessing the files through a mapped drive letter in the guest. This appears to work fine, except when attempting to open any VI or CTL file within the project tree following a Save All, whereupon I get the "x has changed on disk since last saved" warning.
This is bemusing, has anyone seen this before under these circumstances?
12-18-2013 01:43 PM
I also have that error. I am running LabVIEW 2013 on win7-64 bit, and my files are on a file surver. I have no idea what it is or what to do about it.
12-23-2013 08:25 AM
Hi Over_Nyquest,
Are you also using a virtual machine? What do you exactly mean by files being on a server?
When and under what circumstances does the problem appear?
Thanks!
12-23-2013 11:44 AM - edited 12-23-2013 11:53 AM
Hi Mark,
Nope, I am not using a virtual machine.
I have labview installed on my local PC's C: drive. But all of my files (Virtual Instruments, libraries, controllers, and such) are on the departments file server. This way they can be easily worked on be every engineer in the R&D department. I have this file server mapped as a P: drive.
I get this error message sometimes when I'm tiring to open up a top level VI 1st thing in the morning. Other times when I try to open up my top level Real Time VI, Labview just crashes, because that VI has become corrupt. I think these may be related.
12-24-2013
03:09 AM
- last edited on
05-30-2024
02:04 PM
by
Content Cleaner
Hi,
One thing to try is Separating Compiled Code from VIs.
Have a look at the following link: https://www.ni.com/docs/en-US/bundle/labview/page/separating-compiled-code-from-vis-and-other-file-t...
Given your description, it seems possible LabVIEW is detecting the change in compiled code. You can try the method above to unlink the compiled code from the source code.
This may solve your problem, but if the change detected is in the G code rather than compiled code it will not have any effect.
Let me know if this helps.
01-19-2015 04:22 PM
Hello all,
I have the same behavior. Working on LV 2014 on a Win 8.1 x64 Virtual Machine, accessing LabVIEW code on a mapped drive.
Network environment is excellent, all fiber optics.
Did you finally end up with a working solution?
Does Separate compiled code from VIs works? Is this the only workaround? I would prefer not enabling this feature because of its caveats.
It seems LabVIEW doesn't monitor changes in the code on network locations as well as it does on local locations...
Thanks for helping, this becomes really annoying.
Matt.
Matthias Baudot | Software Architect | Founder at STUDIO BODs | DQMH® Consortium Board Member
01-19-2015 05:12 PM
I have labview installed on my local PC's C: drive. But all of my files (Virtual Instruments, libraries, controllers, and such) are on the departments file server. This way they can be easily worked on be every engineer in the R&D department. I have this file server mapped as a P: drive.
Ouch! This means that "every engineer in the R&D department" can change any of the files and it will be difficult to track who did what (not to mention what happens if two people work on the same file, make different changes, and both save -- He (or She) Who Saves Last Wins!).
This is a strong argument for some form of Version Control System! There's a single Repository, everyone "checks out" from the Repository, Commits their changes and Updates changes from others, and problems of conflicting changes are noted and flagged (so you can reconcile them before they get too out-of-hand).
Since the files you are working on, for the most part, stay on your machine, when you update, you only get what your colleagues have committed, so are much less likely to see whole-scale "changed on disk" warnings. Indeed, I've been working on a project with probably a thousand files, and typically see only a handful change when I do an Update (and that's because only those changed files were committed previously).
Bob Schor