LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Write to Spreadsheet File writes only NULL characters

I appreciate that you are reluctant to share your code.  So I wrote some of my own.  It's a utility that creates data using Write to Spreadsheet, 10 rows of 100 random entries.  There is a single control, "Wipeout", that, if set to True, wipes out your data after writing it, and if left as False (default), does not do the wipeout.

 

I'm sure your code is more complex than this, but could it have a "feature" like this buried inside it?  This seems to me much more likely than a function that has been present in LabVIEW for, what, a decade or more?, would, itself, wipe out data.

 

Wipeout Bug.png

Bob Schor

0 Kudos
Message 11 of 22
(1,579 Views)

Reluctant to share code?

 

Why?

 

Maybe he doesn't want thers to see that it is his code that is at fault.

0 Kudos
Message 12 of 22
(1,571 Views)

"Write to Spreadsheet file" writes formatted, humanly readable strings, so a result of 0x00 (which has nothing to do with NaN!) is not directly possible unless it is part of the format wired to the function. This would be the first thing to check (set the format to \-codes to see the non-printables). Also see if the wired "delimiter" constains garbage.

 

I would also check/scan the HD for errors and such. Could be a hardware issue.

 

How about a full virus/malware scan?

0 Kudos
Message 13 of 22
(1,565 Views)

"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."

 

I said that I can't directly post my code (company policy) but I can post a similar piece but it wasn't my point of the thread. Which of the 31 instances would you like to see and I'll extract what I can?

 

I recreated your piece of code and that is NOT the behavior I am referring to. What your code does is completely overwrites the file. My problem is not a problem with a file of no data, it is a file of, in one case, 55.5MB of "\00" characters (aka NULL characters).

 

I have attached one of the output files that was created when this problem occured. As you will see, it is full of NULL characters. Not no data at all but NULL characters.

0 Kudos
Message 14 of 22
(1,558 Views)

@nyc_(is_out_of_here) wrote:

Reluctant to share code?


Some companies have strict policies. What if he would accidentally post the full code of a commercial product? 😮

0 Kudos
Message 15 of 22
(1,554 Views)

... or it is proprietary and there is "compensation" involved ...

 

But we can, at least, demonstrate a plausible cause for the unexplained behavior the Original Poster observed.  It would be a courtesy if he/she checked over the code and let us know if, indeed, it was a "programmer error" rather than an NI "bug/feature".

 

BS

0 Kudos
Message 16 of 22
(1,554 Views)

@altenbach wrote:

"Write to Spreadsheet file" writes formatted, humanly readable strings, so a result of 0x00 (which has nothing to do with NaN!) is not directly possible unless it is part of the format wired to the function. This would be the first thing to check (set the format to \-codes to see the non-printables). Also see if the wired "delimiter" constains garbage.

 

I would also check/scan the HD for errors and such. Could be a hardware issue.


 

My delimeter is hard wired everywhere to be a ","

My input format string is generally not wired and uses the default "%s" that NI provides. I explicitally handle the conversion of data into strings due to the various types of data I am dealing with prior to compiling the data into a combined array for output to a file. And most of that data conversion is double to string.

 

I've already scanned the HD and verified no problems exist with the HD. No bad sectors, no file system issues. Came up clean.

0 Kudos
Message 17 of 22
(1,549 Views)

@Bob_Schor wrote:

... or it is proprietary and there is "compensation" involved ...

 

But we can, at least, demonstrate a plausible cause for the unexplained behavior the Original Poster observed.  It would be a courtesy if he/she checked over the code and let us know if, indeed, it was a "programmer error" rather than an NI "bug/feature".

 

BS


I've checked over my code numerous times trying to figure out this issue. That was the first thing that I did. I've tried to create numerous other pieces of code to replicate. I've gone through and tried unicode characters and other strange characters as inputs. I did a search for everywhere that VI is called (it's 31 different VIs). In at least 85% of the places, the code looks exactly like this (the other places are where files are created and the difference is the append is wired as false and not true but those routines are only called once and the sizes of the files substantiate that):

write-code.PNG

 

So, what that leaves is what could possibly be in an array as a string that would cause the output to go to absolutely all NULL characters. Which was exactly my question from the start.

 

I created a ticket at NI. I've created a small EXE doing read/write in a loop that mimics the behavior in my full program and have that running in the background.

 

As I stated originally, I thought it was an invalid character data that caused it. But, it very could be that the LV run-time engine got into a funky state because the program had, potentially, been and executing for a series of 4 days. It could have been a computer related issue. I've not ruled it out. But, again, my point was to see if anyone else has seen this and maybe get an idea of what is the cause or find out if it is an issue worth bringing to NI's attention.

0 Kudos
Message 18 of 22
(1,529 Views)

@J.Busby wrote:
My input format string is generally not wired and uses the default "%s" that NI provides. I explicitally handle the conversion of data into strings due to the various types of data I am dealing with prior to compiling the data into a combined array for output to a file. And most of that data conversion is double to string.

OK, I was under the impression that you write numerics, not strings. If you write strings, all bets are off, because the first element of the array could be a string containing a huge number of nulls.  Show us your "conversion".

0 Kudos
Message 19 of 22
(1,523 Views)

The conversions are (each one is its own VI called by everything to clean up block diagram):

 

BOOL:bool-conv.PNG

 

Double: dbl-conv.PNG

Timestamp (conv VI is just the double conversion VI):time-conv.PNG

0 Kudos
Message 20 of 22
(1,517 Views)