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.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 7 File not found, but then it is found

HI,
I am using LV 8.0.1 with Windows XP and I'm trying to use the Read Characters From File vi in my application executable.  Strange thing is that it throws "Error 7 occurred at Open File+.vi:Open File" and when I click Continue it open the file I specified in the path and reads it just fine.  All of the correct data is read from the file and is all present.  The whole annoyeing this is that the program stops execution while the LV is running the Error handler.  If LV is obviously finding the file and reading it correctly, then why is it throwing the Error 7?
Please help, this whole problem is driving me nuts!
0 Kudos
Message 1 of 6
(3,150 Views)
One thing I have seen is that if Windows takes a long time finding and loading a file, it will return an error.  But once you clear the dialog box, the file it "couldn't find" opens up just fine.  I'll usually see this when opening a VI in the Labview development environment (once in awhile other applications like opening a file off the network.)  That dialog box is a Windows dialog box, but perhaps it is the same scenario in your situation.  Is your dialog box a Windows dialog or Labview dialog box?  Perhaps it is the same windows error but is passing the error to the Labview error handler.  How is your error handling wires set up from that read characters from File VI?
0 Kudos
Message 2 of 6
(3,148 Views)
The Read Characters from File.vi is a function provided by LV under the File  I/O tool palet.  It handles all of the file open, read and close functions and all of the associated error handling wires.  Upon further examination though I do not even know how it is getting to the read portion of the steps because the error is occuring the the open step, and once an error occurs the next steps should not do anything except pass the error through.  To your point though about Windows taking a long time to find a load a file, I am trying to read a file across a network.  But becasue the Read Characters From File.vi was wirtten by LV, I cannot accommodate network lag in the timing of the VI execution, unless I write my own Read Characters function.  The error dialogue box I am getting is generated by the LV General Error Handler.vi so it is a LV error
 
Also something very frustrating is that I did not have this problem for all of the previous 3 year that the application has been running.  Which tells me that it may be something external to LV and something of a problem with the network.  There again though nothing changes (that I am aware of) between yesterday and today.
0 Kudos
Message 3 of 6
(3,143 Views)


Gravy Train wrote:

unless I write my own Read Characters function. 
I would suggest you do that, at the very least to avoid having a VI which can pop up a dialog. This VI is very old and not written in great style.

___________________
Try to take over the world!
0 Kudos
Message 4 of 6
(3,134 Views)
I looked for that VI in LV 8.0 but couldn't find it on the File I/O Pallette.  Luckily I still have 7.1, and was able to find it there.  It must have been carried along from an earlier LV version of your VI.  Good news is that you can open that VI and see what it going on inside.
 
Anything error handling that causes a dialog box to pop up unwantedly and pauses a program you want to keep running is a bad idea.  I think you will need to create your own version of the Read characters VI.  But you won't have to start from scratch.  Save a copy of that VI under a different name.  It is not well designed as it does not allow an error wire to be passed in or out which violates a log of style guidelines.  Wire in your own Error In control and Error out indicator and connect them to the connector pane.  You may have to reorganize the connector pane as it does not follow the guideline of 4-2-2-4.  Get rid of the general error handler and just wire  the errors to the error indicator.  Then in your program, you can do some special error handling for that particular error.  Perhaps allow a timeout case or something after the open VI in the subvi and try to open again.  Delays in network communications could certainly cause such an error to be raised.
 
Side note:  The open VI in that VI looks like it is an older version as well called Open File+ and has a dialog box as well embedded.  So you may want to replace some of the other File I/O functions with the newer ones found in LV 8
0 Kudos
Message 5 of 6
(3,130 Views)

Thanks guys, rewriting Read Characters From File vi sounds like the way I will go.  It is still frustrating to not konw why it work for 3 years and then suddenly "No Dice"  Strangely enough, as I was finishing up my last post, my two local NI sales contacts walked into my office, so I got to beat them up for a bit about this problem.  They had similar advice as you guys posted about rewriting the VI to conform to better programming style, they also suggested to load the NI development environment out on my application computer to trace throught the execution problem exacly as it is happening on the application.  Unfortunately that is kind of a drastic approce, but if I want to truly get to the root cause, that may be the only path.

 

Thanks

0 Kudos
Message 6 of 6
(3,127 Views)