Write to Spreadsheet File writes only NULL characters

[J.Busby]

We ran into a weird scenario where we had data being written to CSV files come out as only NULL characters (\0 when read in Labview, 0x0 when binary read as a U8 array). I have 300+MB in different files that only contain NULL characters.

We have 10 different data types that get saved into separate files by mostly separate pieces of code that ALL had this same problem. The same basic process happens for each of the 10 data types:

1) User is prompted to enter in testing information (UUT SN, Operator, Temp, Test Condition (type of test, etc.).

2) Filename is generated based off time to split the data into files per hour (individual filesize management)

3) A common typedefed cluster is then processed and added as a data description header (5 string values and a ring converted to a string)

4) A header row for the data columns is then added to the description header

5) All collected data is stored into memory and auto-saved to their respective files every 5 minutes (memory control and data loss preventation in case of a crash)

Steps 3 & 4 are only done if the file is new (i.e. its a new hour or the first save cycle). Step 1 is done once at the start of the data collection.

This code has been working for over a year and even handled this length of testing we did (3 hours) numerous times. This was also using an built EXE.

My best guess: Somehow the array to spreadsheet string or write text to file VI got into some fringe state and it was just writing out NULLs. To me, that is the only way that all 3 hours of all 10 data types exhibit this issue (30 files). Maybe some sort of weird character that the operator entered?

The sizes of the files almost exactly match the expected size given the test length and data collected, it just shows up as only a NULL. I did not do the test but was told that they potentially had the computer lock-up and they restarted it but that was 4 hours after the start of a 3 hour test.

Not necessarily looking to recover the data as I've tried basically everything, just looking to see about possibly preventing this from happening again (which might never happen again).

[richjoh]

---

@J.Busby wrote:

 The sizes of the files almost exactly match the expected size given the test length and data collected, it just shows up as only a NULL. I did not do the test but was told that they potentially had the computer lock-up and they restarted it but that was 4 hours after the start of a 3 hour test.

---

Sounds like a computer lock-up and the program was not taking measurements thus the null value (NaN). Some hardware peripheral maybe.

Rich J

[J.Busby]

Well, I would think the same, except that (and I didn't lay this out there so, shame on me):

1) Our unit is a command/response system. We were commanding a motion profile, it was moving and we were receiving the data back. That is our primary data point(s). We were receiving the data back because the GUI displays the data and the operator did not have issues monitoring the data on the screen (or the test would have been stopped and the problem investigated). The point in the code where the data is displayed is the same place where it is stored in the code.

2) If it was only a measurement issue, the files should still contain the string based header information and it does not. The file is entirely NULLs. No header info or data, period.

3) If you take NaN and do a Number to Fractional string conversion, you get NaN as a string, which would then be saved to the file as NaN and not \0.

4) A lockup at 4 hours after a 3 hour test does not explain the reason why data that had not been touched for over 2 hours would be corrupted. The lockup, if there was one, would have been at the end of the test when attempting to stop the test (again due to #1 above) and therefore would only cause 5 minutes of bad data and have 2 hours and 55 minutes of actual data.

Again, the file is completely NULLs. There is nothing readable in the file at all. Not even the string input and string constants data.

[J.Busby]

I should mention this is in Labview 2012 SP1.

[Bob_Schor]

How are you writing?  Can you show the pieces of the code that actually open the file and write the data?

BS

[J.Busby]

Data is being written via the included "Write to Spreadsheet File.vi" in Labview. Here's the context help for it:

It is the NI file but when you open it and drill down, there is an Array to Spreadsheet string component and then the following code does the actual opening and writing of the file:

[Bob_Schor]

Thanks, but you still haven't shown your code that does this.  So I need to ask a silly question -- did you wire a Boolean T to the "Append to File" input?  Also, is there only a single Write-to-Spreadsheet function in your entire program?  [It really is a challenge to help debug a program when you can't see the program you are trying to debug ...]

BS

[nyc_(is_out_of_here)]

We don't have crystal balls.

If you want help, post YOUR code.

Very simple.

[J.Busby]

I guess the purpose of my post was misunderstood. I'm not asking for help in debugging my code as all the signs don't point to my code being the issue (if 9 of my 10 data streams worked and #10 didn't, then absolutely it's my code but to have all instances have the same problem across the board...). I'm asking if anyone else has seen this issue with the NI provided code, what the potential stimulus is/was to cause this issue was so that it can be safeguarded against in the future. This was intended to be a more high-level/general question as opposed to a specific "drill down" question as to how I am using the code.

The "Write to Spreadsheet File" VI is called 31 times in my program (places where I am saving data). I can't directly post my code. I can post a similar example piece of code but again, wasn't my original intent.

Due to the fact that every call to this problematic VI had an issue, the inputs seemingly have no bearing on whether or not they work. Append false or append true, both had the same issue. 4 of the 31 instances use transpose, the other 27 don't. All had the issue. Every instance uses the String version, so that is constant across the board and all had the same issue. The delimeter is always a "," (given the CSV format). I understand that I didn't directly state this and I apologize for that but, as previously stated, my usage of the code was not my original intent.

The bottom line is that the piece of NI code is a black box. I know what goes into the black box and I know what I should get out of the black box. Based on the information I have, what went into the black box was correct but what came out was not correct. The transform inside the black box was changed. What I'd like to figure out is the potential stimulus that caused this. For instance:

- Was it some weird character value input via a control?

- Was it an issue where the Labview engine hiccuped due to the length of time it had been running?

- What would cause a write text to file call to write a NULL character instead of a string?

- What could cause an array to spreadsheet string component to output only NULL characters?

- Why would it also not output any line feeds or carriage returns between each array row?

[nyc_(is_out_of_here)]

---

@J.Busby wrote:

I guess the purpose of my post was misunderstood. I'm not asking for help in debugging my code as all the signs don't point to my code being the issue (if 9 of my 10 data streams worked and #10 didn't, then absolutely it's my code but to have all instances have the same problem across the board...). I'm asking if anyone else has seen this issue with the NI provided code, what the potential stimulus is/was to cause this issue was so that it can be safeguarded against in the future. This was intended to be a more high-level/general question as opposed to a specific "drill down" question as to how I am using the code.

The "Write to Spreadsheet File" VI is called 31 times in my program (places where I am saving data). I can't directly post my code. I can post a similar example piece of code but again, wasn't my original intent.

Due to the fact that every call to this problematic VI had an issue, the inputs seemingly have no bearing on whether or not they work. Append false or append true, both had the same issue. 4 of the 31 instances use transpose, the other 27 don't. All had the issue. Every instance uses the String version, so that is constant across the board and all had the same issue. The delimeter is always a "," (given the CSV format). I understand that I didn't directly state this and I apologize for that but, as previously stated, my usage of the code was not my original intent.

The bottom line is that the piece of NI code is a black box. I know what goes into the black box and I know what I should get out of the black box. Based on the information I have, what went into the black box was correct but what came out was not correct. The transform inside the black box was changed. What I'd like to figure out is the potential stimulus that caused this. For instance:

- Was it some weird character value input via a control?

- Was it an issue where the Labview engine hiccuped due to the length of time it had been running?

- What would cause a write text to file call to write a NULL character instead of a string?

- What could cause an array to spreadsheet string component to output only NULL characters?

- Why would it also not output any line feeds or carriage returns between each array row?

---

The NI code is a black box for ALL of us.

Contact NI using your SSP.