02-22-2016 03:55 PM
Hi all, perhaps an odd question, but I'm scratching my head on this one. Is there undocumented behavior in the read/write binary file function, where U8 values greater than 128/0x80 automatically get converted to the value 0x3F?
I'm trying to use LabVIEW to generate a custom binary file that we'll load into an EEPROM, so all of the data in the binary file is stored as U8 values. I have a "template" file, and eventually I'll get the logic implemented to overwrite the fields with the true data. However, I'm hitting the snag that when I simply read the file into LabVIEW and then write it back out, all values 0x80 and greater are truncated to the value 0x3F. Has anyone seen this before, and is there a workaround?
I've noticed trying to write the value 0x80 directly to a binary file (as a U8) results in 0x90, 0x70 being written to the binary file. This is also rather undesirable, as it is adding extra bytes into the bytestream, and the EEPROM bytes need to be in exact locations.
Solved! Go to Solution.
02-22-2016 04:02 PM
Attach your data file.
What program is giving the images below? Are you sure LabVIEW is writing the bytes differently? I really doubt that.
02-22-2016 04:30 PM
Good call on asking about the program I was using to view the hex data. I was using the Hex Editor plugin for Notepad++ to generate those images. I grabbed HxD, and now everything is behaving as expected.