Prev: error 200279
Next: CMD.EXE Output Not Showing up
From: rolfk on 3 Jul 2008 09:10
lmd2 wrote:here is the same sample app in LabVIEW (not an elegant architecture, but the client wants a literal translation from C to LabVIEW)The sample crashes at this function, and returns INVALID BUFFERif you actually wish to run it I can post the distribution for the DLL as wellThe buffer itself seems not to be initialized prior to calling. So I would concentrate on other possible problems and that would be that invalid parameters for the Init and Start function might cause the Get Packet function to return this error.For instance the wMode and Mode options flags seems not very logical to me assuming they would be probably bit flags and not just numbers. Also their combination by ORing them seems wrong as they would overlap in the bit range of the integer.Rolf Kalbermatter
From: lmd2 on 3 Jul 2008 09:40
The initialize function is working on a dozen other sample apps: yes they are bit flags but if you go to the properties of the mode options menu ring you see that the options aren't integer but 4096 and 8192 respectively. But you may very well be correct but in a config specific to this sample, I was thinking perhaps in the MTi configuration function which has setup parameters for device memory buffer, size in bytes for allocated buffers, etc - but I am using the exact same inputs as the C code - does this raise any flags for you?thanx
From: lmd2 on 8 Jul 2008 08:10
from the client:
"Larry,This is a driver level failure that is being passed up to the library.  The driver portion of the aceGetCh10DataPkt does a check on the buffer it is trying to copy into with the following code:    _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;    }The only way to fail this code block is for the size of the buffer being too small or NULL. There is no other way to get this error code. Maybe it's a bytes -> words problem? The aceMTIConfigure function used kb for all buffer sizes.-Eric"
and my response:
National Instruments also felt that it was something to do with the config of the buffers, but I don't know if it is a byte / word issue.in aceMTiConfiguration I am setting the device buffer to 524288 (512kB).In the C sample, the malloc is done prior to calling aceMTIConfigure. In LabVIEW the memory space for aceGetCh10DataPkt is allocated on the fly when the function is called, I think this maybe the issuelet me run this past NI and see what they can come up with, thanx for the insights
From: lmd2 on 8 Jul 2008 10:10
I tried to create the instance of the bit stream prior to calling the MTiConfiguration function, and then using that bitstream to feed the input terminal of the GetCh10DataPkt function -
same error
guess the problem is that at the driver level, the hardware isn't aware that LabVIEW has allocated this space. Anyone know a work-around for this?


mallocFirst.JPG:
http://forums.ni.com/attachments/ni/170/338556/1/mallocFirst.JPG
From: lmd2 on 8 Jul 2008 11:10
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?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10
Prev: error 200279
Next: CMD.EXE Output Not Showing up