From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
10-25-2007 03:32 PM
10-26-2007 11:33 AM
10-27-2007 10:53 AM
This was one of the tips I mentioned in my first weekly nugget.
-D
05-10-2013 01:34 PM
I am also getting this revert error "vi has changed on disk" most of the time when double-clicking on subvis or opening type defs made in Labview 2012. In my case, it was because I was coding on my company's network which I'm guessing changed the timestamp during scans/backups. Try duplicating the project to your computer to get rid of this error.
10-24-2013 06:56 AM
Hi RJ12,
I am curious if you were able to backtrack the reason in your network and fix it?
I heard about a similar issue, however never able to reproduce it.
10-24-2013 07:13 AM
Hi Ardent,
I am able to reproduce it, but IT could only come up with the reason I gave above and could not fix it. So, I do all my coding locally. Sorry I can't be more help.
10-24-2013 07:55 AM
Hi RJ12
and thank you 🙂
I was able to simulate such a situation - e.g. using a Linux touch command on the (Linux) fileserver, however I was not able to replicate it within our network's settings (presumably because there is nothing that would directly influence the attributes of the files).
Still thank you for your reply, every datapoint is good! 🙂
11-19-2013 04:28 PM
So, is there no solution or reasoning why this is occuring? The same window is popping up on me when I attempt to open a subVI from my caller VI. I made a local copy like RJ12 suggested, and that works fine as a workaround, but I'll need to put this back onto my company's network. The window popped up on me right after I made the changes, saved, and attempted to open it back up again immediately. I also attempted to save all the caller VI's until I reached the main VI, but this issue still appeared.
11-20-2013 08:41 AM
Here is a little more info from IT: if the network file (.vi) was infected(or was thought to be infected) and our virus scanner picked it up it alters it (timestamp change) as it tries to correct the issue. We are using Kaspersky for our network scanning antivirus. I have had various issues with Kaspersky and Labview when programming locally as well. There are some mentioned in the forums, but nothing else to do with this error.
12-06-2013 08:48 AM
Hello everyone,
we have another possible reason - our customer tracked the issue to SMB2 protocol's 10s cash.
Turning off the protocol on client side (see here) fixes the problem. We'll be working on finding a solution to work with SMB2 protocol turned on - I will post here about the progress.