LabVIEW
WriteDelimitedSpreadsheet corrupts file when trasposing
Hi everyone,
I am having a very strange bug on which I want to print information to a file. The information is int the array control of the vi I have attached.
The problem I am having is that If I print the array as is to the file it all goes fine, but if I try to transpose it, the resulting file gets corrupted, like that:
I have created a snippet (the one attached) that just tries to write the array if you want to check it out by yourself.
I also tried transposing the array before feeding it to the WriteDelimitedSpreadsheet function but resulted in the same corrupted file.
Anyone knows what I am doing wrong? Am I using any forbidden character/format that makes LabVIEW go crazy?
Hi Antonio,
@antoniobeta wrote:Anyone knows what I am doing wrong? Am I using any forbidden character/format that makes LabVIEW go crazy?
Whenever there are problems with CSV files then it is usually Excel going crazy because of some (invalid) assumptions done by Microsoft…
There are some problems in your VI:
- Your data array contains a mixture of plain ASCII strings and Unicode strings, resulting in a lot of NUL characters in the resulting CSV file. Those NUL chars might irritate Excel…
- Your way to create a new filename results in a file suffix unknown to Windows. Excel might get irritated by this file suffix (and the NUL chars in the file) while trying to import your data.
- For my European Office settings the default separator char is the semicolon, using it helps Excel to import your files…
The resulting files are both simple CSV text files, readable by any text editor! Both files contain EXACTLY the data of your array control…
No, nothing gets "damaged", the transpose switch does the job as should be.
You have some multibyte characters used in your strings, and visual appearance depends from viewer used for displaying. Here how it looks on my side when delimited with semicolon:
In worst case you can always check hex representation to be sure that the content is fully OK:
@antoniobeta wrote:
Thanks for your help, but I need to use tab as the separator. Will investigate the multibyte characters you are mentioning.
I used semicolon just to open this in excel, which is expect this by default. For sure, you can use Tab, which is default for SubVI.
What you can try - just remove all zeroes from the strings, may be after that this will appear normally in your environment (I don't see any chars in your array which will be affected by this action):
Just as an additional comment
Here's one of my plain text files that got misinterpreted by notepad, but looked fine in notepad++.
For some further reading, see here ("Bush hid the facts") . Wile Microsoft apparently fixed some of the bugs, others still remain. I would recommend to install and use Notepad++ (free, open source).
Note that the above was in Windows 10. It actually works correctly in Windows 11. It is possible that they fixed this problem with an update, because I actually reported this file to Microsoft last summer. 😄
(Windows Notepad 11.2402.22.0)
Thanks all for your responses. @altenbach Thanks for the links I will investigate them.
You all were right, the null characters and the Unicode/ASCII confusion were the reasons I was not getting the results I wanted.
I trace the problem to the part of my code translating the hex data to ASCII. Here on the highlighted constant, I had a U32 type which resulted in a bigger data type which LV filled with 0s. Changing that to U8 resolved the issue.
It is the solution suggested of eliminating the null characters but done on the root of the problem.
@antoniobeta wrote:
Thanks all for your responses. @altenbach Thanks for the links I will investigate them.
You all were right, the null characters and the Unicode/ASCII confusion were the reasons I was not getting the results I wanted.
I trace the problem to the part of my code translating the hex data to ASCII. Here on the highlighted constant, I had a U32 type which resulted in a bigger data type which LV filled with 0s. Changing that to U8 resolved the issue.
It is the solution suggested of eliminating the null characters but done on the root of the problem.
Of course you always got the result you wanted and reading the file back with LabVIEW properly would faithfully restore the data later at any time. The ONLY problem was with windows Notepads ability to display the content correctly. A cosmetic issue outside of your control.
Of course whatever you are doing with the code in the picture does NOT translate "HEX data to ASCII" (a very vague term!) for example you seem to be creating binary data from hex formatted strings. Binary data has no business in text files! Period. Human readable text file should not have nonprintable characters except well known delimiters. Why not write the original hex formatted string instead? A string of characters is just that. The ASCII standard just assigns meaning to bit patterns and how they should be interpreted by display devices..
It is possible that I misunderstand your code. Can you attach your VI containing some typical 40 character inputs string? Are you writing that "operator ID" to the text file?
