From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
05-26-2008 03:27 PM
05-26-2008 05:22 PM
Hi Peter,
It's possible to pack a U8 array in LabVIEW and pass it to a DLL (using Call Library Function) so that the DLL gets the structure it needs - assuming the structure doesn't have pointer or class elements. If you're very lucky, it's simple, but more likely will be a bit tricky. The .h file describes the order and number of bytes to pack in the U8 array.
The number of bytes required for each structure-element is determined by the DLL's compiler. Rarely, but possibly, the DLL will require "byte padding" for structure elements.
Usually:
"char" and "small int" is packed as a one byt (U8).
[unsigned] "int" is probably packed as two bytes U16 & I16
[unsigned] "large int" is packed as four bytes - U32 & I32.
"float" are (usually) IEEE-754 compatible as are LabVIEW floats, may mean double-precision (DBL) or single-precision (SGL)
NOTE: AS YOU PACK THE ARRAY, ALL NUMERIC TYPES MAY NEED TO BE BYTE-SWAPPED because of "big endian"/"little endian" considerations (you should research these terms). LabVIEW uses "Big Endian" format,
Use LabVIEW's "Cast" function to get the bytes of any basic type.
There are lots of posts on this subject, do your homework, give it a try, if (when -) you post back, please provide the .h file!
Cheers.
05-27-2008 12:33 PM
05-28-2008 01:21 AM - edited 05-28-2008 01:26 AM
@peter-biomed wrote:Hello,I've been trying to use a dll provided to me within a labView program. The dll requires using specific data types defined by .h files that have been provided to me. These data types are generally structures with a variety of words, floats, and chars making up its components. Is there a way to set things up so I can use a call libray function node that is actually informed as to the data types from the .h files. I noted this post ( http://digital.ni.com/public.nsf/allkb/44F329CAC8052A0386256F0F0050F196 ) speaking to this on a somewhat simpler basis, but could not derive my solution from it. Does it involve including the .h files in \cintools\ or actually within extcode.h itself? I'm imagining that this may be a no-go anyway, I just wanted to know for sure. As well, no, re-programming the original dll so that the structures are decomposed within the functions themselves won't be an option at this point.Anyway, much thanks if anyone can help, even if it's simply directing me to the right help documentaion (or telling me I'm trying to do something that is currently impossible).
05-29-2008 12:04 PM
Hi Jared,
In my experience, it's often not possible to simply pass a LabVIEW cluster for interpretation as a Struct. Classic Windows DLLs (such as USER32.dll) expect Littlle Endian format for numeric types, LabVIEW uses Big Endian (I doubt the Call Library Function can be made "smart" enough to automatically "fix" this in calls to arbitrary DLLs; as of LV 7.1 it wasn't). Some DLLs (compilers) need to have data stored on even or quad-byte boundaries - so where LabVIEW will pass a U8 immediately followed by the second element in a cluser, the DLL may EXPECT byte padding after a single char, to "align" struct elements!
Cheers!
05-29-2008 04:51 PM - edited 05-29-2008 04:52 PM
@tbd wrote:
Hi Jared,
In my experience, it's often not possible to simply pass a LabVIEW cluster for interpretation as a Struct. Classic Windows DLLs (such as USER32.dll) expect Littlle Endian format for numeric types, LabVIEW uses Big Endian (I doubt the Call Library Function can be made "smart" enough to automatically "fix" this in calls to arbitrary DLLs; as of LV 7.1 it wasn't). Some DLLs (compilers) need to have data stored on even or quad-byte boundaries - so where LabVIEW will pass a U8 immediately followed by the second element in a cluser, the DLL may EXPECT byte padding after a single char, to "align" struct elements!
05-29-2008 06:10 PM
rolfk wrote:
LabVIEW uses in memory whatever endianess is the prefered way for the current platform. The problem you describe only happens if you Flatten or Tyepcast between stream data (byte array) and 2, 4, or 8 byte integers since the LabVIEW Flatten and Typecast functions by default assume Big Endianes on the byte stream side and perform byte, and word swapping for 2 byte and bigger integers.
The Flatten/Unflatten function now has an endianess selector input but often is not so useful in this respect since it prepends an additional int32 length parameter for the byte stream side.
And as long as you can avoid the use of the Typecast function, there is no endianess problem at all in conjunction with the Call Library Node. Consequently it's not the task of the Call Library Node to be smart about endianess since its not its own problem at all.
Byte padding is a problem yes, but simply one you need to be aware of. It's always possible to emulate a specific higher byte alignment but never a lower than what the own system uses. So since LabVIEW uses packed bytes you can emulate any other alignment by adding dummy fillers whereas with the opposite (LabVIEW for instance always aligning to 32bits) it would not be possible to interface to packed byte aligned DLLs.
Rolf Kalbermatter
05-30-2008 05:42 AM
@tbd wrote:
Your reply refers to integers explicitly, though, aren't flattened and cast floats also byte-swapped?.
05-30-2008 01:21 PM
Thanks everyone for the useful information.
Having looked a little deeper at the header files (attached here with the dll), I don't think I will be attempting to using this method in the end for this application. Though I was only looking to use a subset of the functions, I'm not sure it will be worth the bother. Essentially I wanted to be able to load a specific file format (from Cambridge Electronic Design) in LabView, but I think I will be using another approach by exporting first in a simpler format.
Nonetheless, I did try a few things. I noted the import library wizard just completely barfs out as it doesn't seem to be getting what it needs from the .h files. Some of the structures are structures within structures, and it doesn't seem to have function declarations that the wizard is able to use. Also trying to use the call library function returns the simple message "The configured return type is not a valid return type. The type is being changed to void." I wasn't quite sure how I could just get it to return me in a simple byte array that I could parse myself, but anyway, as I said I may not try this any further. Nonetheless, the discussion is good for future use by me and others if they should find it. And just to note, I do try to do my homework, but I must admit finding things of interest in LabView help is often like trying to find the needle in a haystack given how extensive it is. ... I suppose I should've been able to find the import library wizard though (though I think my initial attempt at this stuff was prior to me upgrading my LabView version).
Thanks for all your comments!
06-02-2008 11:08 AM