Read From Binary File doesn´t work on MCB2400 in LV2009 Embedded ARM

[aminat]

Hello,

I try to read a Binary File from SD-Card on my MCB2400 Board with LV2009 Embedded for ARM.

But the output is always 0, if I use my VI on the MCB2400. If use the same VI on the PC it works fine with the same binary file.

The access to the SD-Card on the MCB2400 works in other cases finde, if I try to read from a text-file it works without any problems.

Are thre any constraints for the "Read From Binary File"-Node in Embedded in comparison to the same node on PC ?

I have noticed that there is also a problem with the reading of textfiles. If the sice of the file is about 100Byte it doesn´t work anymore, too. I can´t understand it, because I read always just one Byte. And even if the implementation in Labview is so bad that it allways reads the total file in the ram it sould work. The MCB2400 has 32MegaByte RAM, so 100Byte or even a few MegaByte should work.

But this doesn´t seem to be the Problem for the Binary-Problem. Because even a 50byte Binary-File doesn´t work.

bye & thanks

amin

[aminat]

The 100Bytes Problem ist solved. The reason was, that the SD-Card was too slow. Now with a "Sandisk Extreme III" it works without any size limitations.

But the "Read from Binary" Node still doesn´t work.

[Gmg]

I'm not able to test the binary write now, but I can think of a way for you to work around this issue.  Just use a typecast to convert to a string and use the write to text primitives:

[NicB]

With a 16 MB heap by default, MCB2400 target can handle easiely such convertions for scalar arrays with resonable sizes.
After dragging the snippet posted by Gmg deselect Convert EOL for both writing and reading VIs. EOL convertion should not be done if those bytes are not part of a string (e.g. we can get three bytes written in file for particular single precision floating point numbers).

Binary writing/reading in LabVIEW is done element by element, in contrast with "Text" ones where all bytes are passed to low level functions. This might result into a slower execution observed in embedded targets (e.g. for complex elements which for the endianess should be change), but binary variants eventually work.

Still, if the Read from Binary is not working on your target you should post the VI/project.

[aminat]

Hello,

thank you for your Help.

But I just want to read a Binary File, which is build by another program. And this is coded with 8Bit (like a normal Binary File) and not just with 7Bit (ASCII). So the workaround doesn't work in my case.

I posted the Test-VI in my first post (here once again as picture). And it works fine on the PC, but if I try it on my MCB2400 the "Read Form Binary File" Node doesn't work.

And it is also possible to open the Bin file with the "Read Text File" Node and see the cryptic content of the Bin-File. So the Problem seems to be in the "Read Form Binary File" Node.

bye & thanks again

amin

Message Edited by aminat on 09-30-2009 03:28 AM

[aminat]

Hello,

now I tried to build a String compatible Bin File out of your example:

The strange thing is that it still uses just 8 signs for a 64Bit double.

So I tried to read the new file like this on the PC:

And it reads the first values right but after some values it doesn´t work anymore. It seems it writes some instructions like tab into the text file, which it can´t read right. If I try this on the MCB2400 I have exactly the same problem.

[aminat]

Sorry,

NicB already wrote the solution for the error in the workaround.

Just disable the EOL:

So this workaround seems to work.

But it would be still nicer if the normal "Read from Binary" Node works on the Hardware.

But thanks for the workaround !

amin

[Gmg · Accepted solution]

I know you've already resolved this issue with a workaround, but I did some digging around in the source code to find the source of the issue and found the following:

The binary read/write primitives currently do not support the "byte order" input.  Thus, you should always leave this input as default ( or 0), which will use the native endianess of the target (or little endian for the ARM target).  If you wire a value that is different than the default, the primitive will return an error and not perform a read/write.

So theoretically...  if you go back to the very original VI that your posted and remove the "byte order" input on the binary read, it should perform a binary read in little endian.

This also brings up another point:

If a primitive isn't doing what you expect it to, check the error output.

[aminat]

Hello,

thanks for your response.

This would be just another workaround for my case bekause I need "little-endian"-Byte-Order, but it´s interesting to know what is the reson of this problem.

And in this error-case I never got any errors out of the "error out" of the node.

bye

amin

[aminat]

Hi,

today I received a email from the NI-Support, and they wrote the same solution. But they wrote the default value on ARM is "little endian", wehn I don´t connect it (different to the help of the node, which says "big endian"). So I tired it, but all values are wrong.

bye

amin