using AO subsystem on USB-621X interferes with AI subsystem

[sradbil]

I'm having a problem with the USB-621X family, specifically a USB-6211 and USB-6218.

This problem does not occur with a USB-6255, PCI-6251, PCI-6229, PCI-6014 or a simulated USB-6211.

The problem:

I have 2 tasks. One with AI channels the other with AO channels.

Starting and stopping the AO task seems to corrupt the AI subsystem and DAQmxReadAnalogF64() returns this error:

 DAQmx Error: Measurements: Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples
 available sooner, increase the sample rate. If your task uses a start trigger,  make sure that your start trigger is co
nfigured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If
this is the case, supply an external clock.
Property: DAQmx_Read_RelativeTo
Corresponding Value: DAQmx_Val_CurrReadPos

Property: DAQmx_Read_Offset
Corresponding Value:


Task Name: _unnamedTask<0>

Status Code: -200284

Attached is a C program using DAQmx calls that shows the problem.

It started out as the Acq-IntClk.c standard NI demo, hence the name.

The program takes the DeviceID and an optional second parameter that controls whether or not the AO task is created.

Run it as  

VC_Acq_IntClk.exe Dev6 no

 to run on Dev6 and not use the AO subsystem.

Run as

VC_Acq_IntClk.exe Dev1

to run on Dev1 and use the AO subsystem.

When the AO subsystem is not used the program runs all 10 iterations on all devices.

When the AO subsystem is used the program errors on the 2nd or 3rd iteration only on the USB-6211 and USB-6218. 

What is going on with this family of devices? 

How can I write a program that uses both subsystems on the USB-6211 and USB-6218.

Thanks in advance for the help. 

[S_Hong]

Hi sradbil,

It seems that this bug is reproducible and we are currently having R&D looking into this issue. Could you tell us which version of the DAQmx drivers you are using?

Also, perhaps you could describe to us the purpose of your application and see if we may be able to find a workaround to this problem.

[sradbil]

Hi S_Hong,

Thanks so much for the answer.

I have seen this behavior with NI-DAQmx 8.3, 8.7.1 and 8.8.

This code is part of a much, much larger application in which we are trying to acquire data and generate data using the same physical device.

We find this works with all the devices listed above and only fails on the USB-6211 ad USB-6218. This leads me to believe that the entire USB-621X family is affected though I have not tested them.

Is indeed the entire USB-621X family affected?

Are there other affected devices that I should avoid for this application?

[stilly32]

Sherryl,

We're investigating this behavior. From what I can tell this is isolated to the 621x devices and does not effect other lines. From the troubleshooting I've done so far,  the cause of the failure is starting/stopping the continuous AO task so quickly. When I place a 100ms delay or place an DAQmxIsTaskDone call between starting and stopping the AO task I don't ge the timeout. Also, if I use a finite generation (since you're starting and stopping anyway) then I don't get the timeout. 

Do these suggestions work for you? We'll still fix this behavior, but it will likely wait until a future release. 

Thanks,

Andrew S

MIO Product Support Engineer

National Instruments 

[sradbil]

Hi Andrew,

Is there a way to find out the CAR ID for this  problem so I can see when it is fixed.

Looking at the NI-DAQmx 8.9 release notes Fixed Issues section I don't see any CAR that looks like it's this issue.

If you know which release the fix will be in and can post that too that would be great.

Many thanks,

Sherryl

[stilly32]

Hi Sherryl,

This does look like it was resolved in DAQmx 8.9 but as it ended up going to the HW group for a fix we didn't get it in the DAQmx Readme. I'll make sure we get these in the readme in the future. The CAR ID was 123818 if you need it for future reference. 

Thanks, 

Andrew

[sradbil]

Hi Andrew,

I've tried NI-DAQmx 8.9 with the original Acq-IntClk.c that you can find in my first post above and I still get the -200284 error so whatever was fixed in 8.9 does not seem to help me.

I'm curious if this is a fix in the software driver or if I need to somehow update the firmware of my USB-621X device.

Could you clarify?

Thanks,

[Aaron_W.]

Sherryl,

With DAQmx 8.9 do you see the exact same behavior as you did before. Have you tried this application with DAQmx 8.9 with another device than the USB-621X family? I want to make sure it was the same exact behavior as before. If it is the same I will bring this issue up again with R&D and make sure they know of the issue. Thanks. 

[sradbil]

Hi Aaron,

Yes, with 8.9 I am seeing the identical behavior to what I saw in all the previous versions that I tested.

You can see this with the program attached to my original post.

As mentioned both in my original post andin the reply by Andrew S on 08-21-2008 this problem is and always has been isolated to the USB-621X family.

Thanks for the help,

[Aaron_W.]

Sherryl,

I was able to reproduce this error on my computer as well, I used a USB-6218 and got the error, however when I used my PCI-6221 I did not get the error. I am talking to Andrew S. to see what needs to be done since the issue was not fixed in 8.9.