v8.2.1: generic file i/o error while loading VI's

[brian_g]

Hello,

I had a large LV application open and running fine.  I closed it, and upon re-opening the top-level VI it gives "Generic File I/O Error" on several sub-VI's (belonging to me, not LV).  Opening those sub VI's individually reveals no problem at all, and in any case the whole code base lives in a Subversion repository and I have tried checking out a fresh copy of the whole source code tree and the problem re-appeared.  Before Labview displays the "File I/O error" it will hang for several minutes with no disk or CPU activity.

I just tried checking out a fresh copy of the source tree on a separate computer.  Now Labview is hanging while loading "<vilib>:\DAQmx\create\channels.llb\DAQmx Create Channel (CI-GPS Timestamp).vi" after having managed to load 920 VI's.  On edit: I spoke too soon.  It is now duplicating the "Generic File I/O Error" on one of my sub VI's.

If anyone has any clue to this strange behavior please let me know. 

Thank you,

-Brian


Message Edited by brian_g on 04-08-2008 11:43 AM

Message Edited by brian_g on 04-08-2008 11:44 AM

[TWGomez]

Can you post the error descritption and/or code?

Just guessing, but it sounds like something is not getting released properly. You should go through and make sure all refnums/files are properly closed.

I get a similar error if I try to write to a file that I opened outside labView (i.e. a datafile that I look at between runs, forgot to close and it can't write to it because I have it opened)

[brian_g]

Hi,

That's all the error message is:  "Generic File I/O Error:  XYZ.vi".

I can't post this, unfortunately, the error occurs several levels deep in the VI hierarchy and I can't post that much of the program to illustrate the error.

[Hillary_C_E]

Hi Brian,

This error could be related to the Copy VI. This could also be related to a lack of disk space as documented here. Can you replicate the error by just running the subVIs?

[brian_g]

What I found was this...

My code calls a bunch of subVI's in another directory.  Those subVI's in turn had some unwise paths saved in some of them that loaded other subVI's from a network shared drive instead of the local disk directory. 

The network shared drive had been taken off line since the computer was delivered to a customer last Friday.  When LV tried to load the VI's from the shared drive, it would hang for about 5 minutes, then give the "Generic File I/O Error" with an "Ok" button to continue.  I eventually sat and did this for about 13 VI's, taking most of an hour while waiting for the network reads to timeout. 

Once my now-broken application loaded I was able to successfully re-direct the missing VI's to the local disk, resolving the problem.

The "Generic File I/O Error" message could not be less useful in this case and I'm rather irritated by the genericity of the message.  Something like "Network read failed" would have immediately illustrated the problem and kept me from wasting a whole lot of time deciphering  it.