LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV7.1 Strange behavior with Automatic Error Handling occuring when it shouldn't [LV 7.1 Pro on WinXP for Tablet PC's]

[LV 7.1 Pro on WinXP for Tablet PC's]

I recently let a rather large LV app of mine run in the development environment while I was out for a couple of days. Upon returning I found that the app had hung for ~22 hours waiting for an answer to an Automatic Error Handling (AEH) dialog proclaiming an Error 7 in New File without any indication of the VI hierarchy that called New File.  I set about ensuring that AEH dialogs would not pop up and have not been able to discover how I could have possibly received one in the first place.

Subsequent investigation revealed:

Neither AEH option in Options>Block Diagrams were checked.

Network problems had occurred around the time that the app had hung.  All file paths are network paths when running in the development environment, so the cause of the error was most likely valid, even if the AEH dialog appearance wasn't.

My app has only one instance where the New File primitive is used by me. That subVI and all others above it in the hierarchy DO NOT have the AEH property enabled.  The error out cluster of New File in my subvi is wired.

My app has three instances where New File is called from a vi.lib vi (Open/Create/Replace File.vi, Open Config Data.vi, and Prompt Web Browser Path.vi), none of which have the AEH property enabled.  Nor does any of their calling VI's.  All three instances also have their error out cluster wired.

A utility to examine the AEH property of all VI's (with all top level and dynamic VI's loaded) in memory reported that only 1 of 308 vi's ( RGT Does File Exists.vi from the Report Generation Toolkit) had that property true.  That vi has no subVI's other than the File/Directory Info primitive and no calling VI's in common with any of the vi's that call New File, except a top level VI.

As long as 'Enable automatic error handling dialogs' remains unselected in options>block diagram, I am unable to get an AEH dialog for either the New File or File/Directory Info primitives in a test VI with AEH property enabled and their error out clusters unwired no matter what invalid path I pass to the functions.  As soon as the options>block diagram>Enable AEH dialogs' is selected, both primitives fire AEH dialogs with no error out wired and don't when wired. i.e. works as advertised.

In other words I can find no reason why I should have gotten the problem AEH dialog...

I cannot afford for this app to hang because of a network problem, other portions of the app that were running concurrently correctly handled the error and, had the AEH dialog not appeared, the app would have made corrections or shutdown in an orderly fashion.

Any ideas?

0 Kudos
Message 1 of 3
(2,728 Views)
Some VI.lib VIs have a general error handler hiding deep inside with no connector input to disable it (Read Lines From File comes to mind as an example). You should try searching your hierarchy (including VI.lib, obviously) for simple and general error handlers and, if necessary, replace the VIs that have them with your own VIs, which don't.

___________________
Try to take over the world!
Message 2 of 3
(2,724 Views)

Very good.

Write Characters to File.vi>Open/Create/Replace File.vi>New File

New File throws the error.  Open/Create/Replace strips the hierarchy from the source of the error.  Write Characters passes it to the General Error Handler.  I never looked above O/C/R file in the hierarchy except for enable automatic error handling property.  The tip-off should have been to realize that O/C/R file was stripping the hierarchy from the error and look above that. 

The real irony is that Write Characters was being used to log error cluster data to an error log file...

Save as... Copy without updating... the OEM 'Write Characters to File' is gone from this app.

Thanx (a bunch)

0 Kudos
Message 3 of 3
(2,718 Views)