06-29-2018 08:17 AM
Hello all,
I've build a LabVIEW program using LabVIEW 2016 months ago and keep working on it. Until now I never had issues while openning it. But today it suddenly gives an error saying LabVIEW: Generic file I/O error. Strange point is that, my backup VI having same name but in another part of the PC also gives the same error and can't open backup as well. I would be gratefull if anyone of you would help me in this case.
06-29-2018 08:21 AM
Hi N.,
can you attach your VI?
my backup VI having same name but in another part of the PC also gives the same error and can't open backup as well.
Are these the only VIs not being able to open by LabVIEW?
You surely have a backup on a different PC than your own one, don't you?
And you surely have heard of SCC (source code control) systems, like SVN or GIT, before?
06-29-2018 08:28 AM
Are these the only VIs not being able to open by LabVIEW?
Yes. I am able to open even subVI's I've included within main VI project. But the main VI's it self can't open.
You surely have a backup on a different PC than your own one, don't you?
Backup is in closed circuit network actually which has no physical connection with my PC but accessible over network cable. Eventually, I can't open that one also.
06-29-2018 09:29 AM
Try repairing the LabVIEW installation. It could be an issue with the VIs that ship with LV.
Ben
06-29-2018 09:54 AM
Thanks for reply Ben,
Already tried to repair that didn't work unfortunatelly. Than, I uninstalled and reinstalled the LabVIEW but that didn't work too.
07-31-2018 05:56 AM
Hello
I was wondering if you have resolved your issue?
If you haven't, there is support page on the National Instruments website linked here, which goes through error 6 - Generic File I/O Error. It does through some possible troubleshooting solutions. Have a read through it to see if it might help.
I hope this will point you in the right direction to solve your issue if you are still having it.
Best regards,
Geo
07-31-2018 08:26 AM
While you are trying to get your somehow-now-corrupted-VI back, take the time to put in place some form of Version Control System. Many of us use Subversion, often with the Tortoise SVN "shell" for Windows as the client. Also fairly popular with the LabVIEW Community are Git and Mercurial. Every time you make any substantive change to your LabVIEW code, Commit (SVN term) the change to the Repository. If you move to another computer (or work on your laptop at home), start by doing an Update to be sure you are working on the Latest Version.
If your Company/School/Institution does not maintain a VCS Repository, there are relatively inexpensive ones "out there" on the Web. Don't work without a Safety Net, or as Fabiola calls it, a "Time Machine".
Bob Schor
07-31-2018 10:00 AM - edited 07-31-2018 10:02 AM
@Bob_Schor wrote:
While you are trying to get your somehow-now-corrupted-VI back, take the time to put in place some form of Version Control System. Many of us use Subversion, often with the Tortoise SVN "shell" for Windows as the client. Also fairly popular with the LabVIEW Community are Git and Mercurial. Every time you make any substantive change to your LabVIEW code, Commit (SVN term) the change to the Repository. If you move to another computer (or work on your laptop at home), start by doing an Update to be sure you are working on the Latest Version.
If your Company/School/Institution does not maintain a VCS Repository, there are relatively inexpensive ones "out there" on the Web. Don't work without a Safety Net, or as Fabiola calls it, a "Time Machine".
Bob Schor
Re: Time machine.
I also document any changes in the VI's revision text. That text then makes it's way into the commit text. That way, I can tell you, with complete confidence, exactly when each change was made (and you can take the Time Machine to go back to the very moment the fated code was changed). It takes a conscious effort to do it, but the first time someone asks you where and when a certain feature was introduced, and it takes you all of five minutes to respond with exactly where and when the code changed, it will all be worthwhile.
With SVN (super-easy with the Tortoise SVN shell), you can create a repository of your own in about two minutes, so there's no excuse for not having one. Edit: Actually, if your corporation doesn't allow you to install applications, that's a good excuse.
07-31-2018 10:25 AM
In a worst case scenario, you might want to check if there are any "Previous Versions" of the file by right-clicking it in Windows Explorer and looking at the properties.
This has saved my a few times (on my private PCs, at work we have SCC).
07-31-2018 05:26 PM
@billko wrote:
@Bob_SchorWith SVN (super-easy with the Tortoise SVN shell), you can create a repository of your own in about two minutes,so there's no excuse for not having one. Edit: Actually, if your corporation doesn't allow you to install applications, that's a good excuse.
Excellent point! The virtue of having an SVN Server, of course, is that it is more "available" (meaning multiple machines, potentially multiple users), and is potentially more "stable" (someone else is backing it up, preventing accidental deletion, etc.). But even a Roll-Your-Own Repository is better than none!
I'm not sure i understand your point about Corporation, Installation, and Good Excuse ...
Bob Schor