LabVIEW
Read a .CSV file generated by LabView into Python
Why do you ask about the python on the NI forum and why you ask how to read the file, but do not show the file?
LabVIEW yes, but csv - not (see https://en.wikipedia.org/wiki/Comma-separated_values).
CSV is just text file, it's not an excell-file (open it with notepad++ or any othet text editor).
Error text: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 142
So, you need only 150-200 first bytes for analyse the error
Also you can zip this file, because text files is good for archiving.
But, you've written "Here is an excerpt which I have edited in excel and as far as I can tell has the same format", but I don't see the file
Hi John,
If LabVIEW produces .csv files,
It's not "LabVIEW", which is producing those CSV files. It's a software made using LabVIEW - and it's up to the programmer to create those CSV files. Did oyu ask the creator of those tools made using LabVIEW?
(You also don't talk about "Visual C" when you want to discuss DOCX file format, don't you?)
I'm not clear why a question on the encoding of .csv is not legitimate especially given that the protocol is not fully defined on exactly the point I was asking (encoding)
It's a legitimate question, but your failed in uploading (a part of) your CSV file! By default there should be a comma as separator (CSV = comma seperated values), but for me Excel uses semicolon as separator char: so please show an example of your files!
Use a (better) text editor like Notepad++, cut the file down to the first 1 or 2kB of content, save the file. Then either change the suffix to "TXT" or (better) ZIP the file before attaching!
@MyBrotherJohn wrote:
If LabVIEW produces .csv files, I'm not clear why a question on the encoding of .csv is not legitimate especially given that the protocol is not fully defined on exactly the point I was asking (encoding)
LabVIEW does not produce csv files, but has a tool to generically write arrays into formatted files, given a format, a column delimiter (tab by default, but could be anything such as comma or semicolon. Care must be takes to not create conflict with the decimal delimiter). The row delimiter is newline and there are special codes if the array has more than 2 dimensions.
Any file create in LabVIEW can be given the .csv extension, but that still does not make it a csv file. Even windows does not enforce that a csv file must contain data compatible with the format. It just uses the extension to suggest suitable applications to open it and it is up to the creator if it will work.
You still have not attached your csv file, else we could tell you exactly what the problem is. Most likely all you need is to adapt the python code accordingly.
Do you have the LabVIEW code that writes the file? Maybe you can attach that VI too.
Assuming that your CSV file was created with the Write Delimited Spreadsheet function that comes with LabVIEW there is really nothing special about the file created. And yes this is a big assumption although not entirely unfounded, but there is nothing in Windows that enforces a specific file ending for a specific format. For all it's worth it could be simply written with the Write Binary File function and the file given a CSV file ending just for the lolz of pestering the next user (or not understanding the difference between these LabVIEW functions).
So assuming the file was written with the Write Delimited Spreadsheet function it will then be in ASCII (not UTF-8 or any other Unicode format) although treating an 7-bit ASCII file as UTF-8 should not be a problem (and I'm not really sure how the Write Delimited Spreadsheet function could generate any 8-bit ASCII characters). And since the cRIO is a Unix/Linux platform the line ending will be a single linefeed character, not a carriage return/linefeed combo as is common on Windows.
Then there remain two more possible culprits, the field seperation character can be defined as a parameter to the Write Delimited Spreadsheet format function, so did your daughter really use a comma there? The default for the Write Delimited Spreadsheet is actually a tab. Last but not least you have the potential problem of decimal character difference. While the US uses a decimal point as decimal indicator, some countries in Europe use a decimal comma, which can of course wreck havoc when using a comma separated spreadsheet format. For that reason I usually prefer to use tab separated fields in Spreadsheet files. What decimal character the Write Spreadsheet File function uses is by default defined by the current locale of the system. On the myRIO that is the Unix locale which most likely is set to US/en but on your Windows system that is defined by the settings in your Control panel, and the numeric format can be changed seperately too.
