Troubles with DAQPad-6015 USB and DAQmx 7.x, DAQmx ANSI C libs

[nen]

I try to code soft to manipulate DAQPad-6015 through ANSI C interface. Objective is to generate analog pulses with sharp fronts, and to control voltage during cycle (electrochemistry). Fronts should be controlled separately with much higher acquisition rate (up to 50kS/s on 1 AI channel, no more than 500S), while plain rate is about 10 S/s. I found that after hi-speed acquisitions DAQmxReadAnalogF64 hung for some time, approximately proportional to number of measured samples, and lag is about 0.2-1 S for 100 point. The lag clearly depend on PC (I actually tested 4), slightly - on DAQmx version (more on 7.3, less on 7.4 and 7.5). Lags occurs after measurements- on data transfer?. Not any problem was observed in MAX at much hard timings: 100kS/s, 1k S, at  both continuous and finite mode. What is really horrible- at high acquisitions rates I easily got BSOD in nipalk.sys with KMODE_EXCEPTION_NOT_HANDLED (DAQmx 7.4 and 7.5). All used PC are more or less modern (2- AXP1800 with 512M DDR, 1 Celeron 2.4 with 256 DDR (All – Win2KSP4), 1- laptop AMD 64 3000+ with 512M DDR with WinXP Prof). I tried USB 1.1 and USB 2.0 ports. Compiler: GCC 3.4.2/MinGW, multithreading (native Win32 mode, DAQmx not involved, just to separate interface and measurements). Current operation structure is: 1 cycled continuous low-speed task (1 s, 10 S) and triggered front generation and hi-speed acquisition (separated finite tasks) between low-speed steps.  Lag between low-speed steps is less than 0.05s, as well as after low-speed  and before high-speed one.

Any suggestions?

[ChristopheS.]

Hi,

 Have you try to generate PWM with a counter and use it as the AI sample clock. It is easier and more effective. I think this would correct his problem.

Regards,

[nen]

After long discussions with NI support (thanx for help) I correct code. So, now it is not finished, but looks like it works. However, sometimes I got an simultanious Win reboot (I switched off dump saving so I do not know - is it a same BSOD or not). But it is not regular- actually quite rare.  Primary source of BSODs was an explicit usage of interrupts for  reading:
DAQmxSetAIDataXferMech(****,****, DAQmx_Val_Interrupts);
I remove lags  by some shamanic dances:

1. I call all reading before actual data acquisition and start of trigerring- kind of training?
   
2. I put a Sleep(period) after starting of the counter and triggers- so aquisition starts after first counter signal
3. After all this stuff I got acceptable delays.
   

As I understood, you propose to manipulate counter frequency? I`ll try it later- my soft can not be adjusted easely for it.