05-07-2012 03:32 PM
Hi everybody,
I'm having difficulties in reading a specific .bin file, obtained from a tri-axial accelerometer. I've used previous example VI's, but none of them seem to work or help me solve this puzzle.
So far, this is the VI's I used to look in what format it stores (see attached file..nothing special). I've attached to .bin and .csv file containing the data.
I don't have much experience with LabView, so any help would be appreciated.
Thanks in advance!
05-07-2012 03:34 PM
If you already have the *.csv file, why do you need to read the bin file?
05-07-2012 03:39 PM
The zip file containing the .bin and .csv file is empty...
What application wrote the file? Are you sure it's little-endian? Are you sure that it consists of only 32-bit values?
05-07-2012 03:47 PM
If I open the .csv file in Excel it would not display all data!
When I try to read it in LabView it will say not enough memory to complete!
Both solutions would suite! Any ideas to overcome this problem would be helpful
Thanks
05-07-2012 03:49 PM
@User002 wrote:
If I open the .csv file in Excel it would not display all data!
When I try to read it in LabView it will say not enough memory to complete!
Both solutions would suite! Any ideas to overcome this problem would be helpful
Thanks
*.csv is nothing more than a text file that can be read by Excel.
The fact that you cannot open it in Excel says that it isn't a true *.csv
If it isn't what it claims to be, who knows what is in the *.bin file?
05-07-2012 04:08 PM
Sorry! Here is the .bin and .csv file!
Normally I deal with larger files (bin/csv), because I exceed the total upload size I've replaced them with a smaller data sample
05-07-2012 04:30 PM
You ".bin" file isn't even a binary file!
It's a text file.
05-07-2012 11:27 PM
So if it´s a text file ...than please explain my why my data is stored like this (see below) and how can I convert it to the original?
" FF50D7FF4000FFF0CEFEE0000030CCFFA000FFE0CDFFC0000000C80010000020D20010000040D500700000E
0D9FFE00000E0DA007000FDE0CC00500003810201C0000630EB0120000630FB00C0000840EC00B0000EA104
00E0001271040050001660FFFFF0001750D8FE300007D13507F000F8415908E000FFF15C05E000043143026000
03814003B00003013CFFD00003F12001600002912B00F000FDE12AFE7000FEA11CFEA000004105FE600001D1
23FF400002411100000001A121FE700003C131FEE00003C137FEE00001B148FCF000017138FE900001711DFF4
00002910EFFF0000390FF01A00003E0FA01B0000440FC0210000440F901E0000440FA01600003E0FC00E00003
60FD0090000320FF0100000270FD01100002D0FE0170000290FC01A0000200F70150000190FD0190000180FF01
800001B0FD01400001C0FA0130000230F80160000280F90120000230FF0070000260FE0080000270F900400002E
0F90070000310FB0070000330F60050000350FA0060000380F601000003C0F700F0000380F80120000370FA00B0
000370F90080000380FA0080000300FD00B0000340F90110000330FA00C0000380F70140000330FA00A0000360F
90080000330F900E0000390F "
Thanks
05-08-2012 12:10 AM - edited 05-08-2012 12:13 AM
It looks like a set of hex strings but am not sure about it. Did you check about the data format generated from the Tri-Axial accelerometer? The data you have is not generated by LabVIEW right? you are just trying to read them using LabVIEW (I Guess). Check the Spec of the Device then you may get a solution for this but I believe its a hex data.
05-08-2012 07:44 AM
@User002 wrote:
So if it´s a text file ...than please explain my why my data is stored like this (see below) and how can I convert it to the original?
" FF50D7FF4000FFF0CEFEE0000030CCFFA000FFE0CDFFC0000000C80010000020D20010000040D500700000E
0D9FFE00000E0DA007000FDE0CC00500003810201C0000630EB0120000630FB00C0000840EC00B0000EA104
00E0001271040050001660FFFFF0001750D8FE300007D13507F000F8415908E000FFF15C05E000043143026000
03814003B00003013CFFD00003F12001600002912B00F000FDE12AFE7000FEA11CFEA000004105FE600001D1
23FF400002411100000001A121FE700003C131FEE00003C137FEE00001B148FCF000017138FE900001711DFF4
00002910EFFF0000390FF01A00003E0FA01B0000440FC0210000440F901E0000440FA01600003E0FC00E00003
60FD0090000320FF0100000270FD01100002D0FE0170000290FC01A0000200F70150000190FD0190000180FF01
800001B0FD01400001C0FA0130000230F80160000280F90120000230FF0070000260FE0080000270F900400002E
0F90070000310FB0070000330F60050000350FA0060000380F601000003C0F700F0000380F80120000370FA00B0
000370F90080000380FA0080000300FD00B0000340F90110000330FA00C0000380F70140000330FA00A0000360F
90080000330F900E0000390F "
Thanks
Because whatever program generated that data file also took the data and created a big long hex-formatted string. That does not make it binary. It's simply a big long string with a bunch of letters. What is that string supposed to represent? We can't tell you how to interpret is since we don't know anything about the hardware that you are using. Also, the program that generated the file may have saved the data in a specific way. You need to go back to the documentation for the program that generated that file and find out what the string is supposed to mean.