03-16-2009 07:07 PM
Our DLL writes out arrays of 16-bit, unsigned integers to our own binary format. It's really just an 80-byte, fixed-length header, followed by 2-bytes per pixel for infrared image data.
What's the right way to read that data back into LabVIEW 5.1? I see only two binary file read functions, "Read i16" for signed ints and "Read SGL" for single-precision floats.
Right now I have written a little VI to read them in using Read i16 From File, followed by a byte-swap, but it's only "working" because none of the data in this particular data set is >16383, so the left-most bit is not in play. But this will change with other data sets. The VI is here:
the "DTA" file it reads is here:
and it should look approximately like this when rendered properly:
Thanks!
03-16-2009 09:42 PM
You need to think of those binary file read functions as high level examples and a starting point if you need to read other data types. For example, with the Read I16, there is a subVi called Read File+ I8. The data type is specified there with a To Word Integer function. You can make the function read I8 by replacing it with a To Byte Integer function. Right click on the results in this VI and the top level and select Representation>I8. Save both with new names and you are done.
It's all much easier with a current version of LabVIEW.
03-16-2009 11:12 PM
Heh. I suppose this is confirmation that I have much to learn! I didn't even realize that those were VIs that could be examined and edited; I just thought it was a canned function.
This is my second day using LV, so I'll have to dig into this some more.
Thanks!
03-18-2009 08:38 AM
Hi TheWaterbug,
Yes; in general, the light-yellow functions are what we call "primitives" and cannot be opened; the vast majority of functions on the functions palette, however, are just ordinary subVIs. There are exceptions to every rule, however. For example, the arithmetic functions have properties menus that can be changed, and some subVIs are password-protected by National Instruments R&D (usually, though not always, to protect the end user from shooting themselves in the foot by editing something they shouldn't).