LabVIEW
call library function node: malloc to recieve a struct
@lmd2 wrote:
Hi Rolf
this still isn't working, and after discussing it with my client, it turns out that one of the two arrays isn't fixed length. The cluster contains:
U16, U16, U32, U32, U16, U16, U16[3], U16, U16, U16[1]
he explained that even though it isn't defined as a pointer, the second array is open-ended and only points to the first element
This complicates this, you mentioned
"in the second case you have to treat it as an uInt32 (uInt64 on the upcoming LabVIEW for Windows x64 platform) and do some other magic if you need to retrieve the values."
is this documented somewhere (like a white paper?) or could you possibly eleaborate??
sorry, I really appreciate your help on this,
thanx
lmd2
Well it is only magic as far as LabVIEW programming is concerned. It is otherwise simple C programming knowledge you need to have. Basically you treat that pointer as an uInt32 inside the structure and as soon as you need to get its contents you have to find a way to copy its data out into a LabVIEW structure.
There are two possibilities to do that. One is to write a little DLL that exports a function that does exactly this and call it through the Call Library node. The second is using a Call Library Node to link to the MoveBlock LabVIEW manager function that is actually exported through LabVIEW itself. Do a search on the this site for MoveBlock and you should find several posts of mine about this as well as some samples provided by NI people.
Last but not least since there is a pointer in the structure it is probably allocated by the function returning it and needs to be deallocated later by the caller (that means you). You should in that case get information about how this pointer needs to be deallocated. It's either a Windows API memory manager function that you need to link to using the Call Library Node or a specific function exported by your DLL.
Rolf Kalbermatter
It's not exported by a DLL but by LabVIEW.exe and as far back as LabVIEW 2.5 although as a normal Call Library Node interfaceable export only since around 5.0. Before that it was for use in external CIN code only.
@lmd2 wrote:
Hi Rolf
found this thread (looks good):
http://forums.ni.com/ni/board/message?board.id=170&message.id=281715&query.id=89055#M281715
but the example is in 7.1 and I can't find the MoveBlock function in 7.0
does it exist back then? is it called something else?
I guess I need to know what DLL contains this function, thanx
Message Edited by lmd2 on 06-27-2008 10:35 AM
Normal way of using these functions is by writing a DLL to implement whatever parameter translation is necessary between LabVIEW and your other DLL. You include in the source file for that DLL extcode.h and link it with labview.lib both from the cintools directory in your LabVIEW folder, et voilá!
Since around LabVIEW 5.0 you can import those exports also by entering LabVIEW in the library name (case is important and no exe file ending). This is however only useful if you need to import one or two of those functions otherwise writing a wrapper DLL is simply easier and faster and most important a lot easier to maintain in the future.
One last warning! If you think that writing DLLs in C is to difficult and you therefore tend to prefer to use the direct import method through the Call Library Node instead, all I can say is DON'T! Using the Call Library Node correctly requires you to know at least as much as is necessary to write a DLL. Creating a DLL in C is in fact easier since you do not need to know as much about how a C compiler positions parameters in memory as you do when interfacing a function through the Call Library Node. For instance importing the MoveBlock function for your problem can be configured in about 30 or more different ways. Only one of them is the right one and all other ones can and will crash your LabVIEW program sooner or later.
Rolf Kalbermatter
Asuming that you have configured the parameter to be correctly an array data pointer the only other thing I can think of is that you need to fill in some data beforehand too, as the function is looking at the structure to figure out what it needs to do or simply as a safety check to make sure there is an initialized buffer and not just some garbage.
@lmd2 wrote:
Okay, I think I understand the pointer to a pointer, and MoveBlock, but I am not there yet; the original DLL function call is still returning a bad buffer error.
To allocate space I am initializing an array of U8.
From the C code:
S32BIT dwPktPoolSize = 0x20000;
pPkt = (MTI_CH10_DATA_PKT*) malloc(dwPktPoolSize);
where MTI_CH10_DATA_PKT is the STRUCT
I size my array of U8 to 131078 elements (HEX 20000) and used a cluster to type cast, only I can't type cast cause the CLFN errors out - invalid buffer; am I sizing the array wrong? would that cause the error? I don't see anything else that would return invalid buffer unless the function doesn't recognize the array of U8?
Here is a screen shot of the code:
Rolf Kalbermatter
Several ways are possible but the Typecast one is a good one if you only need to initialize the first struct element in that buffer. Just don't forget that Typecast will standardize your data to Big Endian when turning your cluster into an byte stream so when interfacing with shared libraries on x86 platforms you should first wire the cluster through Swap Words and Swap Bytes before wiring it to Typecast.
@lmd2 wrote:
If I was allocating space by wiring a copy of the STRUCT (cluster) to the node, then I could understand populating the cluster but if I am allocating space with an empty byte array how would I initialize the byte array in any meaningful way?
maybe typecast a struct into a byte array, and then resize the array to 131078 bytes?
Message Edited by lmd2 on 07-02-2008 03:33 AM
Or if you use a recent LabVIEW version use Flatten instead and its type set to "Native, host order". Don't forget to set "Prepend array or string size byte" to False too, just to be sure.
Rolf Kalbermatter
