C++ Application using 6533 DIO (PCI-DIO-32HS)

[Convair]

I am using the 6533 to read 32 bit data from a buffer and write to disk on the PC. The application I have written is in Visual C++ 6.0 on a WINNT 4.0 sp6 machine using DAQ 6.9.1. The problem I am having is the application works fine in the debug but fails in release mode. To the best of my knowlege the daq call DIG_Block_Check appears to be affecting the call stack. The pc buffer that I am filling is about 18 MB and I am not using the double buffer configuration.

I am initializing the card with the following commands:

iStatus = DIG_Grp_Config (iDevice, iGroup, iGroupSize, iPort, iDirection);
//iGroup = 1, iGroupsize = 4, iPort = 0, iDirection = 0

iStatus = DIG_Block_PG_Config (iDevice, iGroup, iConfig, iReqSo
urce, iTimebase, iReqInterval, iExternalGate);
//iConfig = 0, iReqSource = 1, iTimebase = 0, iReqInterval = 0, iExternalGate = 0

I Start the card with:

iStatus = DIG_Block_In (iDevice, iGroup, pRadarBuffer, BUFFER_SIZE);
//buffersize = 4,500,000, pRadarBuffer is a pointer to short (I tried making it a FAR pointer to match the prototype, but this had no effect)

Then I query the status of the reads with:

iStatus = DIG_Block_Check (iDevice, iGroup, puiRemaining);// puiRemaining is pointer to long

It is in the DIG_Block_Check where the access violation occurs.

Does anyone know if I am setting up the card incorrectly?

[Filipe A.]

Hello;

That is really strange. NI doesn't have anything like that reported to its Data Basaes. One thing you can try is to upgrade the NI-DAQ driver to the last released version, and double check if the problem was fixed on that new version.
Hope this helps.
Filipe

[Convair]

Thanks for your response. I just loaded 6.9.2, the latest daq and it still has the same problem. I am trying several different things so far with no success, like making the call an inline function, etc.

I have the Dig_Block_Check wrapped by my own function, and interestinly if I pass any variables into this function I created, I get the unauthorized access in the debug as well, this is why I think the function is mishandling the stack.

Anyway thanks again for your help,

Bob