invalid file refnum vi server

[Stu_E]

Write to Text File – Error

Background: I have a Functional Global (FG) which I use to log data throughout my application.  The host application has mutliple threads, multiple queues and several different file logging activities going on (lots of FGs) and several vi-server "Invoke: Run VI" calls to start and stop subvi's in separate threads.  There is an FPGA interface and a Producer/Consumer Event main loop to handle the user inputs as well as a few queues to buffer data between different threads operating at different speeds.  The application has been going through field testing with moderate success.  

One issue that has come up is the file logging FGs seem to return an error when the File Logging VI starts a new file (the two main file logging VI's start a new file when they reach a configured file entry count).  The code runs without errors when called within a single LV VI (i.e. typical FG calls) and even a second thread started manually (after the init & before close) doesn't cause any errors.  However when the threads (and VI's which call the FG subVI) are called from a separate thread there appears to be a file reference loss and/or file close that is going on (behind the scenes), because I continually get a file-write error and I've traced it down to the file refnum.  What is very interesting is that the file refnum looks correct when probed (i.e. the same value as the previous call that worked), yet the Write-to-Test.vi returns an error.

The error occurs when running one or more threads via vi-server (vi reference, Run VI Invoke node) which call a ‘File write Functional Global VI’ named Log_FG.vi which handles the file open/close and file writing.  The attached code runs fine when run within the main thread (as a normal FG, first bullet / test case below), however when the FG is called from the separate thread launched from the vi server / vi reference it returns the above error (second bullet / test case below). 

More interestingly it appears to be working properly (the log files are written correctly with the correct number of entries and the file wrapping (new file creation) is done correctly)

• Run Test_Log_FG.vi – No Error occurs
• With "Remote Mode" turned off, run Test_Log_FG.vi, data is logged in multiple files in the ./Log directory.  It can be stopped and there is no error
• While Test_Log_FG.vi is running start and stop Test_Log_FG_1_2.vi and there is not error (note be sure to stop it before stopping Test_Log_FG.vi as it will throw an error if the file is closed and data is trying to be written)

• Run Test_Log_FG_2.vi – Error Occurs within Test_Log_FG.vi
• Error occurs in both Test_Log_FG.vi and Test_Log_1_2.vi

• Note: The error happens after the log max entry count is reached (i.e. a quick start and stop will not cause the error, it seems as though when one thread changes the file reference number the other thread doesn’t get updated and tries to write to an invalid file reference, or the file is closed when a thread is stopped, causing a subsequent Add or Close to throw an error or the file reference becomes invalid when a thread is closed - speculation).

Could this be linked to CAR 183624 or CAR 192290?

http://forums.ni.com/t5/LabVIEW/error-1-invalid-in-input-parrameter-NI-488/td-p/1043409

I’ve looked into both and 192290 looks very similar and could be the same error (depending on how the ‘measurement file vi’ is implemented) although the error appears to be tied specifically to the “Write to Measurement File” VI.  I have been unable to find anything else about this error other than GPIB Error 1 being ECIC, link:

http://digital.ni.com/public.nsf/allkb/2FA525A8585A92E9862566EE002A3755#ECIC

I was able to work around the issue by placing a check for “Not a Refnum” VI and a case statement (not in attached) in the ‘Close’ and ‘Add’ cases so that nothing is done with an invalid file reference number, but this seems like a band-aid and I would like to understand what is going on, perhaps this is a bug in LabView.  It could be something I’m doing in the Init case that is incorrect, however because it works fine with two threads without the VI server I’m inclined to disagree.  Shouldn't the FG keep the calls in sequence and if so, then a call to 'Add' which maxes the file, should then go right to 'Init' to open a new file and set the file reference, before any other calls to Add occur.

I’ve tried EOL Convert as well as AutoDispose Reference (Invoke VI – Run) on and off, both seem to have no impact.   Any ideas? 

[Matt.M]

Hello,

Looking at your code I don't immediately see anything wrong with it.  I ran your Test_Log_FG_2.vi and didn't receive any errors while it was running (LabVIEW 2011), or when a new file was created.  I only received an error when I stopped the VI, which was caused by a reference leak.

Using the desktop execution trace toolkit, I traced the leak back to Log_FG.vi, I have attached a screenshot of the leak occurring.  It looks like this happens right after Test_Log_FG_1_2.vi is closed.  This is with the wait turned on.

With the wait turned off the call to Log_FG.vi from Test_Log_FG_2.vi is being prioritized over the calls of the two threads, this means that close is called before all the adds complete.  So when an add is executed after the close is called it returns an error because there is no file open.

I have attached three screenshots.  The first (Reference Leak.jpg) shows that with the wait enabled the reference is lost.  The second attachment (Log_FG_2 closed and ADD gets called) shows that after Log_FG_2 is closed Log_FG gets called to add again, and since the reference was already closed it causes an error.  The third image (Test_Log_FG_1_2 close after Test_Log_FG_2) just shows that Test_Log_FG_1_2 actually closes at a later time than

Log_FG_2 if you compare the time to the second image.

Checking to verify that the reference is valid before executing on it is probably the best way to avoid these errors.

Regards,

Matt