Finding "Error 6 EOF" in an old poorly programmed Labview 7.1 program

[tmbouman2]

Hello,

  We have a very old dynamometer at my work and it runs on LV 7.1. The program, when initially written, did not use error wries appropriately for timing or error handling. Basically all error wires from subVIs were left unwired. We recently switched the main computer to a new computer, because the old one died. Now the program throws the below error at "random" times. By random I mean I have yet to find any logic regarding when it happens. I've been trying for weeks so I can debugg it, but no success thusfar.

Error 6 occured at EOF

Possible reason(s): 

LabVIEW: Generic file I/O error

---

NI0488L I/O operation aborted

From this, I figured there had to be a read somewhere causing the EOF. So I ctrl+f the main VI (which calls 100s of subVIs) and searched non case sensivity for "read" and "eof" I then proceeded to attach a checking sub VI to the error output. See attached EOFErrorCheckSubVI for the block diagram of that. Also see attached "Example" for how I would wire the "Troy Debug" subVI. The SubVI basically clears the error and logs where it happened to a folder. I clear the error, because it does not apppear to have any negative effect to the program other than PAUSING the program. When we see the error, if we hit continue the program proceeds like normal. The problem is the pausing of the program. This dyno runs 24/7 and we do not have someone watching it. So this pausing causes us a lot of delays/headaches. 

My questions:

1) Will EOF only happen when reading? Is there some other VI that could create this error?

2) Is there a way in LV 7.1 to not display this specific error? I'm saying change LV in some way so that this error won't be displayed. This computer only runs this program and does nothing else.

3) If you had a program like this throwing EOF and you had no idea where in the 100s of subVIs it was doing it, how would you try and debug it?

Thank you for your time!

-Troy

[RavensFan]

End of file error is going to occur when reading a file.  I can't think of any other situation where it would happen.

Yes. You can clear that specific error.  I believe there is a VI that does it.  A proper program should have some sort of error handling in it.  Why you get errors now and not before is difficult to say.  Is this running in the LabVIEW development environment?  Or is it a build executable?  Perhaps you were always getting the errors before and just didn't realize it.  There is a setting in LabVIEW options under Block Diagram that tells whether errors are automatically handled.  The default is checked which mean it throws up a dialog box whenever an error occurs that you aren't handling yourself.  (wiring to a structure or another VI, clearing, displaying in an indicator.)  Unchecking that box means you get no automatic error dialog.

To find where it occurs, you can add some error logging to your VI.  I created an action engine VI that I initialize at the beginning of the program with a file path.  I drop this all over my diagram wherever I want to log whether an error occurs.  It takes in the error.  It puts a timestamp to it.  I also have another input I can send in so that I can identify which part of the code it occurred at.  I where a different string constant to each instance as an identifer.  When an error occurs, it combines all of that information into a string and writes it to a file.  Now I can review the file, see the date/time and what error occurred, and at what instance of my VI it occurred at.

[tmbouman2]

Hi,

  I agree the program should handle on its own. I wish it did! haha

This is running in LV 7.1 Development. I knew of the settings you are talking about and had changed them. See attached "BlockDiagramOptions" I have the box next to automatic error handling dialogs unchecked. Any other options I can change?

I believe I created something similar to this. See my first post "EOFErrorCheckSubVI" attachment. I have put this after all reads I can find. Nothing comes up in the log file and I still get the error.

Thanks you for time!

[RavensFan]

I think unchecking that option should take care of it for you.

Your subVI looks like it should log that specific error for you just fine.  Since you have the "This VI" and it saving it grabbing the name.  That should give you a clue as to where the error is occurring.  Only issue is if the higher level VIhas multiple locations that cause an error, you wouldn't know which particular error line caused it.  So that is why I would create one more input such as a string called "comment" into that logging subVI.

Now when you drop that subVI at every part, you can put wire a different string constant such as one saying "UI Loop", or "DAQ Loop", or "Temperature File Saving Loop" or something like that.  Now you'll know which part of the code generated the error and not just which VI it occurred in.

[tmbouman2]

Hi RavensFan,

  Thanks for the reponse! Unforunately, that option has been unchecked for weeks now and I still get the error dialog pop up. I will add the string control input to my checker subVI. Any other ideas? Is there a way to get Labview to not pause when a error dialog is presented?

Or programmatically click at a certain location every second....  😉 haha

Thanks,

-Troy

[RavensFan · Accepted solution]

Unchecking that box should have disabled the error dialog popups.  Unless perhaps some code has an Error Dialog function specifically placed at the end an error wire.  But if so, that error dialog should have been popping up before as well.

Each VI has the ability to handle errors automatically, or not.  But you said you have a lot of VI's and I doubt you would have changed those settings on them all from before.

At the end of the day, I think you are just going to have to beat the bushes on this, figure out where the error is occurring and fix it.  Try using the search functionality to find every instance of a File Read function.  While you may have 100's of VI's, I don't think you would have used that function in more than a few places.

[tmbouman2]

Hi RavensFan,

  Thank you for the time. I  will keep at it then. I've already found 30+ haha. If anyone else thinks of something, please let me know. I'll report back when I figure it out.

-Troy

[Bob_Schor]

I "inherited" a LabVIEW 7 program that was similarly afflicted.  I (also) tried incremental patching and checking.  Then I did what I now advise some of my colleagues to do (they usually don't listen to me) -- I started over.

Actually, before doing that, I did attempt a "Massive Repair".  I went through every VI and made sure there were Error In/Error Out wires, and that the Error Line Ran Through It (with VIs "sitting" on the Error Line).  To my surprise, even before Quick Drop, it didn't take that long to do with with a few hundred VIs, and greatly speeded up the ability to "find the bug" (or error).  One warning, though -- there may be a temptation to "fix bad code" ...

Depending how much time you spend looking for the needle in the haystack, spending some time now "baling the hay" may well pay off in the long run.

Bob Schor

[tmbouman2]

Hi Bob,

  Thanks for the insight. I'll see if I can find some time to start fixing the wiring. The hard part is that ir runs 24/7. So hard to have downtime to debug!

-Troy

[billko]

Surely you have a copy resideing in a repository...?