call library function node: malloc to recieve a struct
in [LabView]
|
Prev: error 200279
Next: CMD.EXE Output Not Showing up
From: rolfk on 8 Jul 2008 12:10 lmd2 wrote:so okay, the hardware driver checks the availavle buffer: _try { ProbeForWrite(pCh10Pkt, sizeof(MTI_CH10_DATA_PKT) + (pdc -> MtiDataPoolBufferSize[Channel] - MTI_POOL_OVERHEAD_SIZE), sizeof(CHAR)); } __except(EXCEPTION_EXECUTE_HANDLER) { return MTI_ERR_INVALID_BUFFER; } and in C the allocation is done thus: S32BIT dwPktPoolSize = 0x20000; /*allocate memory for MTI packages*/ pPkt = (MTI_CH10_Data_PKT*) malloc(dwPktPoolSize); so even if LabVIEW is allocating space, it doesn't have a handle, does it? If the driver is checking for memory with a handle of (MTI_CH10_DATA_PKT) it will fail (?) does this sound reasonable? is there some way to assign a handle to a buffer in LabVIEW?I don't think that is the problem. The only thing I can think of is that the driver is NOT tryng to access the buffer during the call where you pass in the array buffer but only later.That would have to fail since a LabVIEW array buffer is only guaranteed to exist for the duration of the Call Library Call to which it is passed. remember that LabVIEW data is strictly dynamically allocated and the memory belonging to a wire is more or less immediately deallocated as soon as a wire stops to exist in the diagram dataflow. After that if the wire gets not wired further LabVIEW deallocates that array buffer more or less immediately or if you wire it further but to some function that does modify its size somehow it will reallocate it, which most times will cause the buffer to be moved in memory rendering the previously passed in memory pointer invalid.So what you can do for a quick check for this theory is wiring the array as in your last solution where you create it outside the loop but wire it through the data function (with an array output too. Then connect that wire to the loop boundary to cause LabVIEW to hold onto that buffer. Make sure the wire stays existing in terms of dataflow until after you issue the stop command and the state of the driver has finished the stop command.If this solves the problem you want to do something else then that is more robust and logical. That is allocating that buffer as a C size buffer calling into some system API for memory allocation. This pointer is then treated as uInt32 and used whereever necessary and after it is not needed anymore you deallocated it with the according system API.Rolf KalbermatterMessage Edited by rolfk on 07-08-2008 05:50 PM
From: lmd2 on 8 Jul 2008 14:10 Hi Rolf, nice to have you back but if I understood you correctly, it didn't help. I wired the array through to an indicator, to the edge of the while loop, and then out to the loop that closes the execution - same error - INVALID BUFFER functionThroughput.JPG: http://forums.ni.com/attachments/ni/170/338692/1/functionThroughput.JPG wireRetained.JPG: http://forums.ni.com/attachments/ni/170/338692/2/wireRetained.JPG
From: lmd2 on 8 Jul 2008 14:10 Just spoke with the client again, he feels that the issue is that we aren't dealing with a pointer to a struct, but a pointer to a pointer to a struct (he says that the next release of the DLL will simplify this, but for now this is what we have). malloc returns [a pointer to a memory location] to (PMTI__CH10_DATA_PKT*); pPkt is a pointer to that pointer but I don't see how that invalidates the buffer? This has implications for another sample program which I haven't coded yet. It uses this same function "aceGetCh10DataPkt" and then writes a binary file of the raw data begining at location pPkt - the problem here is that in LabVIEW the function (using the CLFN) doesn't return a pointer to the memory location, but rather the cast STRUCT Resolving both these issues seems related, but I am not sure howMessage Edited by lmd2 on 07-08-2008 01:07 PM
From: rolfk on 8 Jul 2008 17:10 lmd2 wrote: Just spoke with the client again, he feels that the issue is that we aren't dealing with a pointer to a struct, but a pointer to a pointer to a struct (he says that the next release of the DLL will simplify this, but for now this is what we have). malloc returns [a pointer to a memory location] to (PMTI__CH10_DATA_PKT*); pPkt is a pointer to that pointer but I don't see how that invalidates the buffer? This has implications for another sample program which I haven't coded yet. It uses this same function "aceGetCh10DataPkt" and then writes a binary file of the raw data begining at location pPkt - the problem here is that in LabVIEW the function (using the CLFN) doesn't return a pointer to the memory location, but rather the cast STRUCT Resolving both these issues seems related, but I am not sure howMessage Edited by lmd2 on 07-08-2008 01:07 PMWell that explains everything. When you configure the Call Library Node to pass in an array pointer it passes in the pointer not a pointer to that pointer. And there is no way to directly tell the Call Library Node to pass a pointer to a pointer. The native LabVIEW handle would be a pointer to a pointer but you can't use that since LabVIEW will on return interprete the first 4 bytes in that memory as the number of array elements that follow. So you will get not the correct data back.The only way that can be dealt with is using a call to an external function to allocate that memory, treat it as an uInt32 as far as LabVIEW is concerned passing it by reference to the DLL and then using a MoveBlock call or similar to copy the data out of that buffer when you need it. Of course don't forget to dispose of that buffer at the end either.Just thougth of something else. You could still use a normal LabVIEW buffer and create a small external function that takes the array configured as C pointer and copies it into an uInt32 that then gets passed as uInt32 by reference to the DLL. Saves you the MoveBlock later on which I would consider a performance gain.Rolf KalbermatterMessage Edited by rolfk on 07-08-2008 10:57 PM
From: lmd2 on 9 Jul 2008 08:40
Thanx Rolf, I had thought from my initial post the syntax made it obvious that this was a pointer to a pointer (though the implication was lost on me, and mostly still is) So now I have a POINTER to a POINTER to a STRUCT, which itself contains a POINTER - (the final array defined only by its first element) Guess I have a big learning curve ahead of me - I have never written a DLL, not even sure where to begin (I haven't had a C compiler in years other than Labwindows CVI). And once I learn how to write a DLL I have to figure out what it isa I need it to do - but I have a direction and can stop wasting time doing wrong things ;-) Thanx for your help and patience - I may come back to this thread in a week or two |