SATA: ERROR: Giving up on I/O [0x35] transfer 0

[chipper]

Wrote code to do a very simple text write to the same file over and over on about a 10 sec loop.  The code was written using all stock tools.  The error msg above would appear and continue to appear on every write attempt.  The drive was formatted using the datalight reliance format system.  Chassis: PXIe 1075, Controller: PXIe-8133.  Tried a new contoller and hard drive with the same results.

Reformatted the HD as FAT32 and the problem went away.

The code opens and writes to the same file each time.  Ran this same on code on chassis: PXI-1044, controller: PXI-8110 with reliance as quick as 1 mS with no problems.

The code is a while loop with Write to text file with hard coded text and hard coded file location with 10 sec wait.  The code will run for several loops and the error will occur at seemingly randon times.

[Ryan_S]

Hey Chipper,

Let me make sure I understand the behavior you're seeing. You have a system with a PXIe 8133 and 1075 and the Reliance File Format with code that reads and writes to/from a file. When you run this code, you get the error "Giving up on I/O [0x35] transfer 0" on every write attempt but the reads complete successfully. So, you reformatted the controller with a FAT32 File Format and the error stopped occurring. I assume this means the program is running as expected?

However, you have another system (PXI 1044, 8110) with the Reliance File Format that successfully runs the same code without error.

Since the issue may have to do with the Reliance File Format, have you tried reformatting back to the Reliance Format since getting the program working with the FAT32 File System? Basically, is it reproducible that every time you format to the Reliance File Format, the code fails to run correctly? Also, since you're using an absolute file path in your program have you tried using a relative file path? For system specifics, can you provide a technical report of your system? The following KnowledgeBase explains how to create a technical report:

Documenting Measurement & Automation Explorer (MAX) Configuration Information

http://digital.ni.com/public.nsf/allkb/271F252B4EF0A2E0862570E70056A1E4

The code sounds fairly simple, but is it possible for you to post it so that I can look through it? Have you tried running other programs on the PXI when it has the Reliance File Format and did they run successfully? So, is it only VIs that access files that throw errors? And, are you running these VIs interactively or headlessly? The answers to these questions may give us a better idea of whats causing this behavior.

--Ryan S.

[chipper]

We are only doing file writes, no reads.  This was the test code that we tried to narrow down the issue.  The original PXI chassis is running several threads acquiring data, sending data to PCs, and processing data.  Its only the file writes that makes it choke.  We tried the code below with reliance and it failed. We then tried that same code with FAT32 and it worked.  So we loaded the original code with original file wites and there are no problems with FAT32.

The original PXI code does interact with PC data but can run stand alone.  We havent had any problems of this type for the life of the project it was only after the intoduction of the file writes that erros occured.

[chipper]

attached is the report

[Ryan_S]

Hey Chipper,

I tried running code similar to yours on a similar PXI controller and didn't encounter any errors. As long as the file hierarchy exists then you shouldn't encounter any problems. However, I would recommend that you use the standard format of Open, Write, and Close when accessing files where you can Open and Close the file reference outside of the while loop. As for the technical report, was this created on the system that was reformatted to FAT32 and is now performing properly? I ask because the file system reported in the Technical Report is Reliance. Or have you reformatted this controller back to Reliance and, if so, is it still throwing this error?

--Ryan S.

[chipper]

I noticed that in the report also but the file system is FAT32.

[Ryan_S]

Hey Chipper,

The technical report generated by Measurement & Automation Explorer (MAX) pulls the file system from the controller, which appears to indicate Reliance. What method are you using to confirm that the file system is FAT32? What I believe occurred with your system is that at some point the OS, or other software deployed to the target, became corrupted. Reformatting and reinstalling the software resolved the issue.

--Ryan S.

[chipper · Accepted solution]

I reran the report this morning after some testing had completed and the report came back different from before.  The report today is FAT which is consistent with what we formatted it at days ago.