Error -200016 on DAQmxStopTask

[sentieri]

Error -200016 on DAQmxStopTask

I wrote a simple program in C++ using the NI_DAQmx interface for the PCI-6221 and I am having problems to figure out why I am getting errors on the DAQmxStopTask.

The program is a loop like that:
1.    DAQmxCreateTask
2.    DAQmxCreateAOVoltageChan
3.    DAQmxCfgSampClkTiming (clk=833KHz)
4.    DAQmxWriteAnalogF64 (45 samples)
5.    DAQmxStartTask
6.    Wait 5 seconds
7.    DAQmxStopTask
8.    DAQmxClearTask
9.    DAQmxCreateTask
10.    DAQmxCreateAOVoltageChan
11.    DAQmxCfgSampClkTiming (clk=10KHz)
12.    DAQmxWriteAnalogF64 (9 samples)
13.    DAQmxStartTask
14.    Wait 5 seconds
15.    DAQmxStopTask
16.    DAQmxClearTask
17.    Go to 1 (loop)

My program works perfectly while status messages are being printed on the screen. I am running a remote desktop connection to the Windows XP machine that is running the code. I can see the debug messages on the screen and the generated wave forms on a scope.

When I minimize the remote desktop window, the waveform generated by the steps 1-5 do not report any error, I mean, the status code of these steps is always 0 (zero). Most of the time, DAQmxStopTask (at step 7) returns error code -200016 when the remote desktop window is minimized, what does not happen when that window is visible. I tried to reduce the clock frequency on step 3 to 500 KHz and also to 250 KHz but always got the same result. I tried to introduce a 500ms delay between each step above and it did not work either. By the way, no wave is generated on the correspondent output in cycles where the return of DAQmxStopTask is 20016. I have seen no problems so far with the 10K samples/s wave.

Does the PCI-6221 have an on-board memory buffer? How big is it?
How can I detect (by means of the DAQmx API) that the output signal is not being generated (I mean just in the beginning of the cycle and not on its end)? Is the call back function the only way to do that?

I would say that when the display is minimized on the remote desktop, less resource is being used on the computer running the code and so the computer would have more time available for the DAQmx driver, but apparently exactly the opposite is happening.

Any ideas?

[sentieri]

Just as an additional information, the code is running on a Quad-processor Dell Precision Workstation. This is a very powerful machine. Could the problem be caused by a too fast computer instead of a too slow one?

[sentieri]

I have one more piece of information about this problem. The NI PCI-6221 card was mounted on a PCI-X slot. I have just moved it to a regular PCI slot and apparently my program is working properly now. I still have to do more tests, but one could say that NI driver does not support a PCI-X slot. Does it make sense?

This particular PC has just two PCI slots: one regular and one PCI-X. The other slots are PCI-express. I have to install a huge PCI board in this PC that only fits in the regular PCI due to its size. So the only slot left to the NI board is the PCI-X slot, where it does not work. Does anyone knows about a driver that would work on a PCI-X slot? Or some other way to fix this?

[AdnanZ]

Will a National Instruments PCI Board Work in a PCI-X Bus?

The above link might not help at all but I would recommend contact National Instruments directly to inquire further.

[John_P1]

Hi sentieri,

To say the least, this is very interesting behavior--your 6221 should be able to function properly using the PCI-X bus.  The error you are receiving is indicating that samples are not being transferred fast enough to the 6221.  I would recommend taking a look at the suggested workarounds in the following thread:

Re: 6259 Analog Output error with onboard sample clock

In your case, it sounds like you should be able to regenerate from the on-board buffer without any problems; the on-board buffer can hold 8191 samples shared between channels.  In the C API, you would use the following function to configure the device in this way:

DAQmxSetAOUseOnlyOnBrdMem(TaskHandle taskHandle, const char channel[], bool32 data);

This should bypass the DMA buffer in your computer and write data directly to the on-board FIFO, eliminating the need for the continuous transfers in the first place.  It should be viable for any periodic or finite signal that can fit entirely in the on-board memory buffer.  For larger signals, I would try the other two workarounds mentioned in the above thread.

This problem only seems to appear under very specific circumstances on certain motherboards.  If the DMA controller cannot transfer the data quickly enough, the on-board buffer on the device will run dry resulting in the error.  We will continue looking into the matter, but I would also try contacting your computer manufacturer to see if they can offer any additional insight (or BIOS updates, etc.).  I hope this proves to be helpful.  Thanks for posting!

-John

[sentieri]

Thanks for the information.

I am new to National Instruments devices. I did not find too much documentation about DAQmxSetAOUseOnlyOnBrdMem. I am using it just after DAQmxCreateAOVoltageChan and before DAQmxCfgSampClkTiming (steps 2 and 3 of my first post). I am calling the function using the syntax “DAQmxSetAOUseOnlyOnBrdMem (taskh, NULL, true)”. Could you please tell me if that is what I am supposed to do? Does NI have an official documentation about this function? The documentation that comes along with the card driver seems to be very short regarding to this function, which does not show up under the “NI-DAQmx C Functions” tab in the “NI-DAQmx C Reference Help”.

[John_P1]

Hi sentieri,

The function is actually listed under the NI-DAQmx C Properties tab in the Reference Help.  For your convenience, here's a screenshot from the DAQmx C Reference Help:

Instead of NULL, the second input should be the channels that you want to set to use only on-board memory.  I hope this helps,

-John