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

[Timmar]

Did that very early on - (one of the usual suspects, altough I haven't seen this fix worked /been the cause since 2012 SP1.) Clearing the compiled object cache or re-starting labview are still the most effective methods I have found. 

I am finding Labview crashes/gets muddled whenever I change class data, especialy in a parent class.

I wish I could record one of my programming sessions, you could see first hand how diabolical it is.

iTm.

[Arham-H]

Hi Tim,

I will appreciate it if you can show us via a small sample program the crash you are experiencing as a result of changing the class data in a parent class. I will definitely have a look at it and notify R&D if it turns out to be a bug with LabVIEW.

Regards 

[Timmar]

The problem is that small programs don't tend to crash. It's the larger applications.

It could take days to strip down an application to the point were it might fail,

I would prefer to find a way to get you my full app so you guys can investigate yourselves.

Also, it is unpredictable, my gut feeling is that it is triggere by the number or nature of changes to the class and the timing of saving affected members.

Tim L.

[Arham-H]

Hi Tim,

I agree with you that small programs may or may not crash but large applications can perform differently on different computer, depending on the processor, size of memory available, age of components, etc. This is reason why an issues conveyed via a small program can be reproduced consistently on different machines. R&D could be working on this for weeks and may not experience or be able to reproduce this issue. 

I realize that reducing the size of the program will make more work for you but in the end if I can consistently reproduce this issue it will make a strong case for filing a bug report.

Regards

[Timmar]

Sorry, Arham,

I don't think I have made my point clearly,

In the few attempts that I have made, reducing the program size stops the bugs from occurring at all, making it useless for your R&D guys.

This is why I am offering my complete code for analysis.

I have seen this problem on 4 different PXI controllers, they are dual core 2.5 GHz processors, grunt and memory have never been an issue.

Copying the .rtexe and Hacking the ni-rt.ini file works, so my code should be O.K.

also

Investing several weeks of my time to make an NI R+D engineer's job easier isn't good economics for my company.

We pay a significant ammount of money each year for customer support, This is the sort of service I expect for my 1000's of dollars.

I have recieved great sevice for the "small stuff" from NI applications Engineers and others in this forum, I want to emphasise the importance of your and others work here..

The moment it "gets hard" requiring access to the R&D department the support retracts significantly.

The problem I have listed here should be have been straightforward to diagnose or at least provide some clues:

If I was fault finding my code, I would do a search for wherever "Gereric File I/O Error" & Code:0 was written in the build code and provide a list of events and activities that could cause this.

(If it was my code, each fault would have a unique code or at the very least, a descriptive message that would identify the line of code or operation where it failed).

iTm L.

[Arham-H]

Hi Tim,

We can try to replicate the behavior you are experiencing on our end but due to the size of your project it probably cannot be sent via email or posted on this forum. In this case I recommend creating a service request so that we can follow other avenues for getting your project (via FTP). You can go to ni.com/ask, create a service request and call 1-866-ASK-MYNI (866-275-6964) with your service request number or you can email support@nil.com to start an email conversation.

Hope to hear from you soon.

Regards,

[Timmar]

My Problem has mysteriosly gone away.

After the f5 patch

Thanks to all that contributed.