LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 5 occurred at Delete

Hello,
 
I am converting a PDA vi to a normal vi and am getting the "Error 5 occurred at Delete" whenever I try to delete an empty file.  The block diagram snipet that does this is shown below.  The 1st frame checks to see if the file length is 0, the 2nd frame closes the file.  Neither of these frames generates any errors. The FALSE case in the last frame does not attempt to delete the file because if the file has data (size>0), then it needs to be kept.  This operation works fine in the PDA vi, but gets the "Error 5" every time in the normal vi running on my computer. The only thing that is different in the vi between PDA and PC versions is the path location of the file.  The other thing that I don't understand is that Error 5 says it is a GPIB error requiring the GPIB board to be the system controller.  I am not using GPIB at all in either PDA or PC version of this, so the description of error 5 makes no sense to me.  Any help greatly appreciated.  Jerry
 
0 Kudos
Message 1 of 5
(6,924 Views)
First, your screen shot does not show because it points to an image located on your harddrive, which of course we don't have access to.  You must attach the image (preferably a .png) to your message then post it.  Then if you want to embed it, you go back, edit the message, and add the image and have it point to the location on the NI server which can be found by right clicking on the attachment shown in the posted message and select properties.  Copy and paste that string your the dialog box that pops up when you want to attach the image.
 
Error 5  says:
 
Error 5 occurred at an unidentified location
Possible reason(s):
LabVIEW:  File already open.
=========================
NI-488:  Command requires GPIB Controller to be System Controller.
 
The GPIB part of the message is usually meaningless because most people aren't dealing with GPIB.  It just happens to be there in case you are because they use the same error numbers as regular labview errors.  The important part is the "File Already Open"  Hopefully that gives you a clue as to why the file may be considered open on your PC but not on the PDA.
0 Kudos
Message 2 of 5
(6,923 Views)

Sorry about the bad image post.  First time I've ever tried one and it displayed OK in the preview. I thought the website uploaded the image file from my system.  I have tried to attach it as a png below per your advice.

The "file already open" is what is confounding me because I close the file immediately prior to trying to delete it and the file close vi shows no errors.  If I stop the vi using a breakpoint after the file is closed, all indications are that the file is in fact closed. I can access it, edit, delete, etc., but I still get the error 5 "file already open" from the delete vi.

Thanks and Happy Thanksgiving,



Message Edited by vsaone on 11-22-2007 09:17 AM
0 Kudos
Message 3 of 5
(6,897 Views)

Ravens Fan,

I finally found a sub-vi where the file in question was being opened twice, so that was the source of the error.  The app and the Delete vi worked fine on the PDA even with this mistake, but apparently either LabView or WinXP is more persnickity about this than is the PDA. Seems like this problem would be easier to prevent if LV would warn about opening an already open file, but maybe there are reasons to allow it?

Thanks for your help.

Jerry

 

0 Kudos
Message 4 of 5
(6,883 Views)
Hi Jerry,
 
That's great!  I'm glad you found it.  There may be some logical explanations behind opening files that are already open and whether it causes problems or not.  I came across different scenarios when opening a text file I was periodically logging data to.  My LV program would append data to a file about once a minute.  I could open the file in notepad to view it without issues.  It seems that notepad doesn't create any lock on the file that prevents other programs from opening it.  Thus my LV program could continue to append data to the file.  One time I tried to open it in Excel so I could do some data calculations (which of course took longer than a minute), but Excel seems to put a file lock on it that prevented LV from opening it and appending data.  The error was propagated where I not only lost that batch of data to be logged, but subsequent data because even after I closed the excel file, the error prevented following iterations from executing to open and append new data.  I learned that if I wanted to open the data file in Excel, I would make a copy of the text file first.  I also fixed my sub-VI so that the error wouldn't propagate to later iterations of the logging loop thus preventing further loss of data in the event I still made a mistake by opening the file in a program that locks it.  The difference between the PDA and the PC may be just in the way the operating system handles file locks.
 
I thinking that the constants that determine the access mode during the file open (read only, write only, read/write) may have an effect on it as well, but I've never played with it to find out.
 
Happy Thanksgiving to you as well!
0 Kudos
Message 5 of 5
(6,878 Views)