LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Help reading binary file

Solved!
Go to solution

Am picking my way through the file using your original one as the starting block. I am having issues with the float though as i have tried a couple of different things but am having no luck with these sections. i am currently up to the frequency which should read as 100.

 

Any suggestions as it looks like the remainder uses float as well for the data points.

 

Cheers

0 Kudos
Message 11 of 22
(1,267 Views)
Try changing the data type that you give "Read from Binary File" to a either a double or single precision floating point number. To do this right click on the number and change its representation.


Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 12 of 22
(1,261 Views)

You could ask if NI has a DataPlugin for this file.

 

There is a link on the DataPlugin page where you can request that NI help write one, and there is an SDK on the same page that might help you deal with the details of endianess and floats.

 

 

 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

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

Doofus wrote:

Am picking my way through the file using your original one as the starting block. I am having issues with the float though as i have tried a couple of different things but am having no luck with these sections. i am currently up to the frequency which should read as 100.

 

Any suggestions as it looks like the remainder uses float as well for the data points.

 

Cheers


A float would be 32 bits, so in LabVIEW you'd use SGL. You skipped the Dataset offset field, and you need to be consistent in the way you're reading the data. I'm not sure why you were reading only 1 byte for the "Number of bytes in the trial name" - that's a WORD, so it should be 2 bytes. I also don't understand why you were adding 1 when reading the strings. These are not C strings. They have an explicit length, so adding 1 to the number of bytes to read is incorrect. See attached modification which reads up to (and including) the frequency.

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

smercurio_fc,

 

Thanks for all your help so far. im sorry to hassle you but if you are willing can you help me some more with this. I have tried to continue reading the binary file but am having no luck with it. The software version that the program uses is version 8 so i am guessing that i can ignore the next section up to the trailer block flags. This section is where all i seem to get are 0's and i cant then start to read the data block. Looking into the program help section it appears that as long as the default files havent been altered there shouldnt be anything in the trailer block.

 

Would really appreciate if you could spend more time on this but i understand if you have better things to be getting on with.

 

Cheers

0 Kudos
Message 15 of 22
(1,223 Views)
After the frequency you need to read either 2 bytes (a U16) or 4 bytes (a U32) depending on the version. You would read a U16 if the version is 5 or 6 and a U32 if it's version 7 or greater. So, in you case, you need to read a U32 after the frequency. This is the "Parameter set creation flags." I have no idea what these flags mean - it's not defined in the file format spec, so there must be some other documentation on what the flags mean. After that the "Trailer block flags" is another 4 bytes, or a U32.
0 Kudos
Message 16 of 22
(1,216 Views)

smercurio_fc,

 

I am still having problems with this file. I followed your advice and continued onto the next sections. I have had a look through all the program documentation but can not find anything relating to the parameter set creation files but am wondering if this is throwing out the following sections.

 

Using the data file i have continued on to the parameter set label. I seem to have a problem with the user bytes though as the number of bytes being read is zero so that when i wire that into the user bytes nothing happens. if i leave the number unwired into the user bytes then it reads the number of bytes in the parameter set label as being 256, which is combining both the parameter set label and the following parameter set unit label. 

 

any suggestions - of course this is all stopping me getting to the data section which is really all i am after!

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

After reading the User Bytes you need to read the Parameter Sets. The Number of Parameter Sets was previously read and it was found to be 12 for your file. This means you need to drive a for-loop using this number wired to N. Inside the loop you read a WORD (U16) to read how many bytes are in the label, and then you read that many bytes to get the label (a string). You can auto-index the output of this second read to get an array of strings. You then follow that with another loop, also with the Number of Parameter Sets wired to N to read the parameter set unit labels.

 

At least that's what you would do. It appears there are two problems:

  1. The file format spec is ambiguous. The section where it talks about the parameter set creation flags implies with the IF statements that you would have one of those conditions. Looking at the file, however, it appears that each one is there, regardless of the version of the file. Thus, after the frequency you have a WORD, WORD, DWORD, regardless of the file version. One of them will have data (potentially), and the others are simply zero since they don't apply. Thus, you always have to read a WORD, WORD, DWORD after the frequency.
  2. The above will get you to the user bytes section, but there's another problem here. The number of user bytes in the file says 1, and you're supposed to read that many bytes to get the user bytes. Unfortunately, that's not what I see in the file. I see the 01 00 to indicate 1 user byte, but the sequence afterwards is 00 00 00 00 in order to get to the 06 00 which is the number of characters in the first parameter set label, which is "sacrum". This doesn't make sense. Is the file format spec correct? It would help to have another file to look at for comparison. 

 

Aside: can't figure out why you seem to like all those scraggly wires as opposed to my nice clean, straight wiring. You must have that silly auto-wiring turned on. Smiley Very Happy

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

Thanks for your time on this. I did say i was a newbie - cant say the thought of turning off the autowiring even came to me!

 

I have attached a couple of examples of the 3LD files - as far as i am aware these have never been changed but i would not be surprised if the guys behind the program have screwed up the explanation of the files. I take it that ideally i have to hope that the error is consitant otherwise i may be stuffed.

 

Dont suppose you could attach an image of your explanation fo sorting out the number of parameter strings if the above glitch can be solved? I understand what you mean but putting it into practice may be another thing entirely

 

0 Kudos
Message 19 of 22
(1,183 Views)
Solution
Accepted by topic author Doofus

Doofus wrote:

Thanks for your time on this. I did say i was a newbie - cant say the thought of turning off the autowiring even came to me!


Don't worry - I wasn't poking fun at you. I was actually taking a pot-shot at the NI engineers, albeit at your expense. When the auto-wiring "feature" was introduced I thought "Hey! Cool!". Then I saw it in action, and I thought "Hey! This is crap!" Now it's one of the very first things I turn off on new LabVIEW installs (along with the automatic error handling and viewing terminals as icons on the block diagram).

 


I have attached a couple of examples of the 3LD files - as far as i am aware these have never been changed but i would not be surprised if the guys behind the program have screwed up the explanation of the files. I take it that ideally i have to hope that the error is consitant otherwise i may be stuffed.

Unfortunately, I can't really say definitively since each of those files have the number of user bytes set to 1. It could be that the programmers used a DWORD instead of a BYTE for writing out the user bytes, or that they used a DWORD, assuming that there would be a maximum of 4 user bytes. The only way to know for sure is to look at a file that has more than one user byte and see whether the pattern is 02 00 00 00 00 00 00 00 00 00 or 02 00 00 00 00 00. 

 


Dont suppose you could attach an image of your explanation fo sorting out the number of parameter strings if the above glitch can be solved? I understand what you mean but putting it into practice may be another thing entirely

It would be something like this:

 

You'd use the same thing for the parameter set unit labels.

 

Message 20 of 22
(1,166 Views)