Error on RT Deployment "Generic file I/O error NI-488 I/O operation aborted"

[Timmar]

I see the following when I deploy a built RT application:

Deploying MasterController(failed to deploy)
LabVIEW:  Generic file I/O error.
=========================
NI-488:  I/O operation aborted.
Deployment completed with errors

Does anyone know what might be causing it?

The error code is unhelpful as I don't use any GPIB devices, I assume the NI-488 is a red herring

If I simpify the code slightly I can use the same application builder to successfuly deploy.

The built .rtexe runs without problem if I copy it onto the controller and re-boot.

I have dealt with the usual supects: File Path too Long, corrupted project, corrupted VI's.

Any help would be appreciated

[Arham-H]

Hi Timmar,

Please let us know what hardware you are using and also the simplification you are performing on the code. Can you run the RT VI in interactive mode?

Regards

[Timmar]

PXI-8108 RT

PXI-1042

Serial Comms Cards 8433/4

Occurs on 2 different targets, same spec.

Development mode works Fine,

.RTEXE Works Fine (Copy onto controller)

Deployment from Labview project FAILS.

Code is exclusevly LV Class structured

Code simplification - dropping 4 threads and 4 "potental threads"

Nothing noteworthy about the threads.

1 is an additional protocol handler (I have 3 already, this one shares a driver with the other 3) the others are event consumers or "Dead" - an empty array of objects, disabled for this test.  They are "Shells" for override methods containing hardware drivers. These drivers are not in the project.

I was asking for help on the error message to help me pinpoint what module has the error in it.

Tim L.

[Arham-H]

Hi Timmar,

Unfortunately this error is generic and does not give us a lot of information. In you last post you mentioned that when you disable some loops and then perform the RT build, it is successful. What I would recommend is disabling all the other code and enabling the loops which you previously disabled and build the application again to see if you get the same error.

If this error is reproducible then I would really appreciate it if you can size down the loops (so that it still gives the error when building the application) and post it on this thread so that we can reproduce it on our end and perform further troubleshooting. 

Regards

[Timmar]

Arham,

My application has 3,500 vi's and controls in it.  It is a complex application and not exactly portable.

As to isolating the problem, If I had time to do that I would be reporting the findings not the request for help.

The debug/isolation cycle is long. 8 minute build + Deployment.

It disables Labview while I am doing it preventing me from continuing on other work.

I have a workaround that allows me to continue development, so my boss isn't going to pay me days worth of work to debug yet another Labview Phantom buried by useless "generic" error codes. 

Can you contact your R+D group and find out what scenarios can cause the deployment process to report this message.  There can't be too many.  They may even be able to add a useful message.

I can get you the code if you can find a way but I need a comittment that someone is going to look into it and resolve the problem.

I have a dozen others like this that NI have done nothing to help. Some I have figured out, others remain a mystery.

Examples:

Nested Typedefs in NPSV's fail .exe launch

Corrupted Projects

Corrupted VI's

Labview crashes

Broken VI's without error messages.

Long File Paths

Modbus Libraries in Virtual Folders

Self Corrupting Modbus Libraries.

[Arham-H]

Hi Timar.

Please try to rebuild the application with 'Enable debugging' selected. I was talking with a few colleagues and with LabVIEW object oriented programming we have seen ambiguous errors. Usually enabling debigging solves the issue.

As far as what could be causing this, I have asked R&D and will let you know what their response is.

Please let me if rebuilding with debugging enabled resolves the issue.

Regards

[Timmar]

Debugging is already enabled.

I am following another line of investigation at the moment.

I found that, apparently at random, Labview created new VI's as "Inline"  I am on a scavenger hunt to clean them all out.  I suspect I might have missed a few, not that this should cause a problem.

"When you have eliminated the impossible, whatever remains, however improbable, must be the truth"

Thanks for Looking into this one.

Tim L.

[Arham-H]

Hi Tim,

R&D got back to me but unfortunately they could not give me specific situations which would lead LabVIEW to throw the deployment error you are seeing. The recommendation I got was to try and reproduce the error on my setup and then file a corrective action report so that R&D can review the code.

Regards

[Timmar]

Do you need my 4,226 files to do it?

[Arham-H]

Hi Tim,

You can try to create a new project and drag all your files from the old project to the new one and then try deploying. Sometimes object references can become corrupt and if this is the case then setting up a new project should help resolve the issue.

If the issue persists then I will appreciate it if you can condense your code so that the error is reproducible with a minimum number of VIs so that I can notify R&D and they can have a look at the sent files.

Regards