AO with NI 9401 newly created task returns values from previous task

[sradbil]

I was very happy to see that CAR 4D3EQ6AH was fixed for NI-DAQmx 8.7 (see http://forums.ni.com/ni/board/message?board.id=250&message.id=33026) and I've confirmed that for USB-6211 this is indeed fixed. But with the CompactDAQ devices NI 9263 and NI 9264 this is not fixed.

For example, with the NI 9263:

Input device ID (e.g. type Dev1 to get Dev1/ao0 or cDAQ1Mod2 to get cDAQ1Mod2/ao0): cDAQ1Mod2
Before write:  Bytes written: 507
Time delay    10 ms: Bytes written: 3 (Delta: 0)
Time delay  1023 ms: Bytes written: 1026 (Delta: 0)
Time delay  1537 ms: Bytes written: 2563 (Delta: 0)
Time delay  1534 ms: Bytes written: 4098 (Delta: 0)
Time delay  1536 ms: Bytes written: 5634 (Delta: 0)
Time delay   520 ms: First task - Bytes written when done: 6134
Second task - Before write:  Bytes written: 6134
2nd check - Before write:  Bytes written: 6134
Second task - immediately after write: Bytes written: 3
Second task - Bytes written: 503
End of program, press Enter key to quit

and with my NI 9264 we get:
Input device ID (e.g. type Dev1 to get Dev1/ao0 or cDAQ1Mod2 to get cDAQ1Mod2/ao0): cDAQ1Mod8
Before write:  Bytes written: 505
Time delay    12 ms: Bytes written: 3 (Delta: 0)
Time delay  1535 ms: Bytes written: 1538 (Delta: 0)
Time delay  1536 ms: Bytes written: 3074 (Delta: 0)
Time delay  1537 ms: Bytes written: 4611 (Delta: 0)
Time delay  1536 ms: Bytes written: 6147 (Delta: 0)
Time delay   520 ms: First task - Bytes written when done: 6648
Second task - Before write:  Bytes written: 6648
2nd check - Before write:  Bytes written: 6648
Second task - immediately after write: Bytes written: 3
Second task - Bytes written: 503
End of program, press Enter key to quit

I have installed NI-DAQmx 8.7.

I am attaching the test program which is based on the standard example VoltUpdate.c shipped with the NI-DAQmx software.
It is changed only from the program I attached to my original post from 08/30/07
http://forums.ni.com/ni/board/message?board.id=250&message.id=33026

in that you enter the full deviceID rather than just the number.

Is there something more that needs to be done for cDAQ devices or did CAR 4D3EQ6AH not take cDAQ into account?

Thanks in advance for the help.

[ryannorthington]

sradbil,

I took a look at the CAR and I did not see any references to any cDAQ modules. I will look into this further and post back with my findings.

[sradbil]

Hi Ryan,
When I submitted the original problem we did not own any cDAQ modules and I saw the issue only on the USB-6211.
Now that we own cDAQ I see the issue on the NI 9205 and NI 9201.
It has been fixed for USB-6211 as stated in the 8.7 release notes.
So I'm thinking there is more work to be done in the driver to fix it for cDAQ modules.

Thanks so much for addressing this.

[ryannorthington]

sradbil,

cDAQ was in fact not tested when evaluating this CAR.  The issue has been re-opened and we are looking into it.

[stilly32]

Hey All,

This issue was fixed in DAQmx 8.8. It was reported in CAR 66505. 

Thanks, 

Andrew S