Access to 6601 counters from 2 seperate executables with traditional nidaq drvr

[RobbertVision]

Hello,

I have a problem with my application made in VC++6.0. I am using the 6601 together with the Traditional Nidaq 7.4.1 in Windows XP.

I have two instances of an application running on 1 system. Both of the applications have access to the 6601 counter/timer board.

Application1 uses counter 0 and 1, Application2 uses counter 2 and 3. For each app., one counter is used as timebase, the other as single puls generator

This works quit well, but after more than 2,000,000 runs, I get unpredictable behaviour. Sometimes the board doesn't respond, while the program is still running (it does not hang) and the Nidaq functions do not return an errorcode.The board does not change the outputs..

All functions are called inside one thread, which contains a state machine. The state machine is called continuously.

first, the actual counter value is read with GPCTR_Watch(...). After a few states, the other counter is armed for a single pulse generation.

After the pulse is generated, the state machine is resetted to its initial state. This continues infinite

The other program does exactly the same, in parallel, but then with the other two counters.

P.S. Once I experienced that enabling the Power Management and screensaver in WinXP gave a similar behaviour of the 6601 card. But 10 seconds after the screen saver was exitted and the energy saving mode exitted, the card worked back normal again.

I hope someone can help me pinpointing this problem?

Best Regards,

Robbert

[KvZ]

Hi Robbert,

I have not heart of this behaviour before, Is there a need for you to use the NI-DAQ Traditional Driver?

I'm asking because the NI-DAQmx driver which also supports the 6601 and is multi treaded as well. where as the NI-DAQ Traditional driver is not. If the issues is related to the driver being used from two processes this could very well be solved with NI-DAQmx.

Thanks

Karsten

[RobbertVision]

Hi Karsten,

Thanks for you reply. The only reason for using the traditional NiDaq is our experience.  We used it before, and wrote wrappers for all function calls.

I have to take a close look at the syntax of the NI-DAQmx function calls before porting it.

Thanks,

Robbert