LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get Error 6 about 50% of time when building Application

In LabVIEW 2010, I am getting an Error 6 about 50% of the time when I Build my VI into an Application.

 

I may fail several time in a row. It may fail every other time.

 

VI runs fine in LabVIEW debugger.

 

Why does the Build work fine sometimes and Fail other times?

How do I fix this?

 

Error message:

Error 6 occurred at Delete in AB_Engine_Delete_Internal_Files.vi->AB_EXE.lvclass:Build.vi->AB_Build.lvclass:Build_from_Wizard.vi->AB_UI_Frmwk_Build.lvclass:Build.vi->AB_UI_FRAMEWORK.vi->AB_Item_OnDoProperties.vi->AB_Item_OnDoProperties.vi.ProxyCaller

Possible reason(s):

LabVIEW:  Generic file I/O error.
=========================
NI-488:  I/O operation aborted.

C:\Users\Don\Documents\OnSpex\builds\HTT\My Application\Application.exe

0 Kudos
Message 1 of 54
(4,838 Views)

Do you by change have Google Desktop running.  Google Desktop can lock some of the files where we are trying to write to causing this error.

 

Try disabling Google Desktop and see if this error goes away.

 

Also, make sure you don't have any other programs that could be scanning and locking certain files.

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 2 of 54
(4,814 Views)

I am not running Google Desktop. It is not installed.

 

Nothing that I have should be locking files that LabVIEW is working with.

0 Kudos
Message 3 of 54
(4,807 Views)

@Jon S. wrote:

Do you by change have Google Desktop running.  Google Desktop can lock some of the files where we are trying to write to causing this error.

 

Try disabling Google Desktop and see if this error goes away.

 

Also, make sure you don't have any other programs that could be scanning and locking certain files.


I have no Google software installed on this machine.

There should be no other programs working with files that LabVIEW is trying to access.

CPU is fast (i-5, four cores) and access should be good.

 

What else could cause this problem?

0 Kudos
Message 4 of 54
(4,789 Views)

The error mentioned is thrown when LabVIEW is trying to delete the internal files that application builder creates during the build process.  If for some reason LabVIEW doesn't have access or permission to delete the file then this error could be returned. Can you try to reproduce this on another machine, preferably one that is relatively clean?  If not is it possible to post the code so we can try it out here?

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 5 of 54
(4,755 Views)

The machine that this is happening on is very clean. About 1 week old. New Windows 7 Ultimate. Core i5-750. lots of RAM. Very little software installed. Used for LabVIEW dev.

0 Kudos
Message 6 of 54
(4,750 Views)

Code is developed under NDA and can not be shared.

0 Kudos
Message 7 of 54
(4,749 Views)

I don't know why it fails 50% of the time, several attempts only minutes apart.

 

Unlees LV is sensitive to some timing issue. Perhaps the CPU is too fast and checks fail.

LV should be more resilient and should try several times.

0 Kudos
Message 8 of 54
(4,747 Views)

Well we need to see if we can figure out some sort of pattern.  You mentioned about 50% of the time.  Does this always happen when immediately rebuilding?  What happens if you build, manually delete the built files and then build again (repeat if neccesary).  What happens if you continue to rebuild without manually deleting files.  Do you see any sort of pattern.  Do you have the folders/files open when you try to rebuild.

 

If you don't see this happen in the immediate rebuilding case try to remember what you are doing between builds that work and then fail.

 

I'm sorry we can't give you a direct solution at this time but right now we need to see if we can characterize the problem a little bit more.

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 9 of 54
(4,731 Views)

What I did observer is: sometimes I would do nothing.

 

Make edits in VI

Build, failed.

Build again, OK.

Build again, failed.

Build again, OK.

Build again, failed.

Build again, failed.

 

Since I was not making any changes between builds and it would just as likely succeed or fail, I don't think that it has anything to do with the contents or conditions of the files. They should be exactly the same.

 

The one unique thing is that I am running on a very fast machine. Core i5-760 with 4 cores.

 

If it is deleting files and then going back to check is they are deleted, it may see that it appears that the files are still there and haven't been deleted yet.

Or if it tries to delete them before they have been fully closed, it may not have access.

 

Whatever actions or checks it is making that causes this error, I think those actions or checks may need to be made my resistant to possible race or timing conditions and retry multiple times with time delays in between before aborting with the error.

0 Kudos
Message 10 of 54
(4,722 Views)