LabVIEW generic file I\O error

[TITAN-x]

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.

[GerdW]

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?

[TITAN-x]

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.

[Ben]

Try repairing the LabVIEW installation. It could be an issue with the VIs that ship with LV.

Ben

[TITAN-x]

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.

[geokim98]

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

[Bob_Schor]

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

[billko]

---

@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.

[Intaris]

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).

[Bob_Schor]

---

@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