Blue screen lockup with analog voltage measurement (WinXP, PCI-6251)

[Hohum-hrm]

Hello, I'm looking to solve a blue screen lockup problem with my measurement application, which I'm developing with C++. The lockup seems to manifest somewhat randomly after a varying amount (500-50,000) of analog voltage measurements. My application needs to do a huge amount of these digitally triggered voltage measurements after a certain delay, and I'm using a single task to do them. The task is stopped and started after a single measurement is done, which is done around 10,000-100,000 times in a second. This is done because I'm doing synchronized data acquisition with the PCI-6251 card and a Ztec oscilloscope card. It seems that the lockup likelihood might be related to the frequency of voltage measurements I perform.

The application itself is multi-threaded, but I'm blocking simultaneous access to the card with locking - all access to the card is behind a single mutex lock, so concurrent access is blocked. In any case all data acquisition access o the card is behind a single thread, which is dedicated for daq operations. I have also done stress-testing with the Ztec scope card, which didn't result in any problems. I also disabled the Ztec card's data acquisition in order to make sure it wasn't the scope card causing the problems - the problem persisted, so this seems to point to the nidaq card's direction. The lockup appeared when I used the original drivers that came with the card. I installed the newest drivers (removed the device from Windows' device manager and your Measurement & Automation application, reinstalled) but the blue screen still pops up.

The blue screen gives me some debug data but it doesn't seem to mention any .dlls or something that would obviously point to a specific (driver) file. I'm attaching at least part of the relevant code snippets.

[Hohum-hrm]

bool Daq::createPositionReader() {
    mutex.lock();

[..]

    DAQmxErrChk(DAQmxCreateTask("", &task_reader));
    DAQmxErrChk(DAQmxCreateAIVoltageChan(task_reader, chan_name_reader.c_str(), "", DAQmx_Val_RSE, conf_v_es_min, conf_v_es_max, DAQmx_Val_Volts, NULL));

    DAQmxErrChk(DAQmxCfgSampClkTiming(task_reader, NULL,100000.0,DAQmx_Val_Rising,DAQmx_Val_HWTimedSinglePoint, 1));
    DAQmxErrChk(DAQmxCfgDigEdgeStartTrig(task_reader, chan_name_start.c_str(), DAQmx_Val_Rising));
    DAQmxErrChk(DAQmxSetStartTrigDelayUnits(task_reader, DAQmx_Val_Seconds));
    DAQmxErrChk(DAQmxSetStartTrigDelay(task_reader, conf_y_read_delay));
[..]   
mutex.unlock();
[..]
}

bool Daq::measureElectron(f64 *data) {

    DAQmxErrChk(DAQmxReadAnalogScalarF64(task_reader, conf_timeout_es, data, NULL));
[..]
}

bool Daq::stopStarter() {
    mutex.lock();
    DAQmxErrChk(DAQmxStopTask(task_starter));
    mutex.unlock();
[..]
}

bool Daq::startStarter() {
    mutex.lock();
    DAQmxErrChk(DAQmxStartTask(task_starter));
    mutex.unlock();
    return true;
[..]
}

[Hohum-hrm]

And yeah, the functions above are not for the same task - I mistakenly copied start/stop functions that handle another task, which I don't currently use at all, but they operate alike.

[Hohum-hrm]

Bump. 😞

[S_Hong]

Hi Hohum-hrm,

Would it be possible if you can attach a stripped down version of the project, including the main function, so that I can try running the code on our end to see if we can reproduce the issue? Also, I would appreciate if you can give me some small instructions as to what connections need to be made in order to run the code. Hopefully this will help us find what may be at fault.

Regards,

S_Hong

Applications Engineer
National Instruments

[Hohum-hrm]

Hey S_Hong and thanks for your answer! I will try to produce a stripped version that manifests the crash, so I'll get back to you with more information asap!

[Hohum-hrm]

Hello again! I've attached a simple stripped version of the measurement that reproduces the crash. The wiring itself is simple: I have AI0 wired for the voltage measurement and PFI0 which I use for the digital triggering. I use gcc for the compilation (Thread model: win32 gcc version 3.4.5 (mingw-vista special r3)). I used a hardware pulse generator with the frequency set at 49400 Hz (doesn't need to be exactly this...) for the TTL pulse, which I use to trigger and to measure.

[Hohum-hrm · Accepted solution]

Hello again! I was in contact with a local support person, who suggested that I use DAQmx_Val_FiniteSamps instead of DAQmx_Val_HWTimedSinglePoint. I did no other changes but this (shown below) and the problem went away, so this seems like an acceptable solution, as I see no reason why not do it this way. (Thanks Henry!)

    //DAQmxErrChk(DAQmxCfgSampClkTiming(task_reader, NULL,100000.0,DAQmx_Val_Rising,DAQmx_Val_HWTimedSinglePoint, 1));
    DAQmxErrChk(DAQmxCfgSampClkTiming(task_reader, NULL,100000.0,DAQmx_Val_Rising, DAQmx_Val_FiniteSamps, 2));