From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
05-26-2011 12:57 PM
I am attempting to save aquired data to a binary file. This VI takes counts from multiple channels, and displays them as a bar graph. The generated waveform comes out accurately, however the generated text file does not seem to save the data. It is only a few characters long, and I dont seem to be able to interpret it at all. I have tried to save the variant data, and the data after the conversion (before it is graphed). Both files and the VI are attached below. Any advice on where I'm going wrong would be greatly appreciated.
Solved! Go to Solution.
05-26-2011 01:21 PM
What program are you trying to read the file? Are you trying to read it on the same computer platform? The files you uploaded are big-endian, which implies you're probably on a Mac. Are you trying to read the file on a Mac? Are you using some other application that defaults to little-endian? Are you taking into account that the file write is pre-pending the size of the array?
05-26-2011 01:41 PM
This was done on windows vista, and I attempted to read it on windows vista. The program was a custom program written by a co-worker that analyzes the raw data from the unit. Both of us agree that the data is way too short to be anything meaningful. What does it mean to pre-pend the size of an array?
@smercurio_fc wrote:
What program are you trying to read the file? Are you trying to read it on the same computer platform? The files you uploaded are big-endian, which implies you're probably on a Mac. Are you trying to read the file on a Mac? Are you using some other application that defaults to little-endian? Are you taking into account that the file write is pre-pending the size of the array?
05-26-2011 01:47 PM
Shultz,
Do you intend to write a binary file (more efficient, unreadable by humans) or a text file (less efficient, readable by humans)? They are two different types of file.
The code in your screenshot opens a text file but then saves the binary data of the variant. This data is most likely not in ASCII (text) format so when you try to read you see what appears to be garbage (what is really happening is your text editor is interpreting the 1's and 0's of binary variant data as ASCII encoding).
If the graph is displaying correctly then I suspect the UMCBICONN2 GetData is returning an array of numbers. In which case you will want to convert that array of numbers to strings and then use the write to text file VI to save them to disk like so:
Sorry about the screenshot -- I would normally post a snippet or at least attach the VI but I'm working on a development machine that doesn't have a released version of LabVIEW on it and you wouldn't be able to open any VI I saved.
Hope this helps. Regards, Simon05-26-2011 01:47 PM
You will need to see what format the external application expects the data to be in. You may need to write you own conversion routine in LabVIEW to format the data in the same way the external application is expecting to see it. Have you looked (used a probe) to see what the data you are writing? Is the data there but the external application is expecting a different format and misinterpreting the data.
By default the Write to Binary File VI prepends the data length to the file. That is, it writes a 4 byte value to the beginning of the file (and possibly each call) which specifies the data length of the record.
05-26-2011 02:01 PM
@Simon H wrote:
Shultz,
Do you intend to write a binary file (more efficient, unreadable by humans) or a text file (less efficient, readable by humans)? They are two different types of file.
The code in your screenshot opens a text file but then saves the binary data of the variant. This data is most likely not in ASCII (text) format so when you try to read you see what appears to be garbage (what is really happening is your text editor is interpreting the 1's and 0's of binary variant data as ASCII encoding).
If the graph is displaying correctly then I suspect the UMCBICONN2 GetData is returning an array of numbers. In which case you will want to convert that array of numbers to strings and then use the write to text file VI to save them to disk like so:
Sorry about the screenshot -- I would normally post a snippet or at least attach the VI but I'm working on a development machine that doesn't have a released version of LabVIEW on it and you wouldn't be able to open any VI I saved.
Hope this helps. Regards, Simon
I would preffer a format that is readable to a human. Dont worry about the screen shot, it is very helpful. I will modify my program as mentioned and get back to you.
05-26-2011 02:22 PM
@Simon H wrote:
Shultz,
Do you intend to write a binary file (more efficient, unreadable by humans) or a text file (less efficient, readable by humans)? They are two different types of file.
The code in your screenshot opens a text file but then saves the binary data of the variant. This data is most likely not in ASCII (text) format so when you try to read you see what appears to be garbage (what is really happening is your text editor is interpreting the 1's and 0's of binary variant data as ASCII encoding).
If the graph is displaying correctly then I suspect the UMCBICONN2 GetData is returning an array of numbers. In which case you will want to convert that array of numbers to strings and then use the write to text file VI to save them to disk like so:
Sorry about the screenshot -- I would normally post a snippet or at least attach the VI but I'm working on a development machine that doesn't have a released version of LabVIEW on it and you wouldn't be able to open any VI I saved.
Hope this helps. Regards, Simon
For right now, this does exactly what I need. Thank you for your quick response!