07-08-2008 09:43 AM
07-08-2008 10:50 AM - edited 07-08-2008 10:50 AM
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.
@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?
07-08-2008 12:42 PM
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
07-08-2008 12:57 PM - edited 07-08-2008 01:07 PM
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 how
07-08-2008 03:54 PM - edited 07-08-2008 03:57 PM
Well 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.
@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 how
Message Edited by lmd2 on 07-08-2008 01:07 PM
07-09-2008 07:34 AM
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
07-09-2008 02:20 PM
Hi Rolf
may I change the subject for a moment and ask you another question?
I have another function with 4 inputs, DevNum, Enable, IRQ Mask, and a pointer to a user defined function.
The user sets the IRQ mask, and if a defined interrupt occurrs, the user function gets called; the prototype looks like:
S16BIT _DEC aceSetIrqConditions(S16BIT DevNum, U16BIT bEnable, U32BIT dwIrqMask,
void(_DEC *funcExternallsr)(S16BIT DevNum, U32BIT dwIrqStatus));
How do I configure a function's input to accept a pointer to another function?
thanx
07-09-2008 03:42 PM
07-09-2008 04:39 PM
That's the more simple solution. You do not strictly need a DLL wrapper since you can also call DSNewPtr in the same way as MoveBlock directly from LabVIEW (and of course don't forget to call DSDisposePtr at the end).
@Jared_B wrote:
Rolf,
So you would then recommend allocating the memory for the Array in the wrapper DLL. Passing the pointer to that memory location back to LabVIEW as a uInt32, and getting the data from that memory location with the MoveBlock?
07-09-2008 04:43 PM - edited 07-09-2008 04:44 PM
I've written elsewhere here already several times about this. And the answer is you basically don't and can't!
@lmd2 wrote:
Hi Rolf
may I change the subject for a moment and ask you another question?
I have another function with 4 inputs, DevNum, Enable, IRQ Mask, and a pointer to a user defined function.
The user sets the IRQ mask, and if a defined interrupt occurrs, the user function gets called; the prototype looks like:
S16BIT _DEC aceSetIrqConditions(S16BIT DevNum, U16BIT bEnable, U32BIT dwIrqMask,
void(_DEC *funcExternallsr)(S16BIT DevNum, U32BIT dwIrqStatus));
How do I configure a function's input to accept a pointer to another function?
thanx