DO task randomly stops (no errors generated)

[josborne]

Hmmm.  So according to your second post, the buffer is not at actually being filled up, right?

Also, if the buffer were being filled up, then I should definitely be getting an error.

[Mcdan]

The VI you posted has a sample rate of 100 kS/s, which would correspond to a default buffer size of 100 kS.  When you begin an acquisition, we continually schedule transfers with the OS's USB stack.  As these transfers complete, data is transferred from the OS's transfer buffers into DAQmx's buffer.  When DAQmx buffer is full, we stop scheduling these transfers and allow data to back up into the devices's FIFO.  My guess is that the code which handles transferring data from the USB transfer buffer to DAQmx's buffer will wait until there is enough room in that buffer to transfer all the data from the completed transfer.  Since you're waiting for the same number of samples to be available as the buffer is large, I think you could end up in a situation where the buffer isn't full, but there isn't enough space in it to move data from a completed transfer.  At this point, your code is waiting for data to show up in the buffer, and the code which wants to put data in the buffer is waiting for more space to become available.  As such, we stop scheduling USB transfers, and data backs up into your device's FIFO until it runs out of space (and you get the strange FIFO overflow error).  I'm thinking that if you increase the buffer size, that you'll avoid this particular condition.

Hope that helps,

Dan

[josborne]

Ah, ha!  Kudos again!

Methinks you are on to something!

This is a rather difficult condition to understand, and kind of hard to workaround since we have such limited control over the underlying transfers.  And we also can't monitor how full those underlying buffers are.

I actually think my application is getting stuck in this sort of "race condition" at other times, also.  Though, I am having trouble demonstrating it because it takes a random amount of time to happen.

In my actual application (not the example I have uploaded), I am acquiring data at 5kHz and my buffer size is 25k n(or 5 seconds worth of data).  And it appears that it freezes up at odd times.  Particularly if my OS is busy doing other stuff.

[Mcdan]

DAQmx does expose a couple of advanced properties by which you can modify it's default behavior.  They are:

DAQmx Channel->Analog Input->General Properties->Advanced->Data Transfer And Memory-> USB Transfer Request Size and USB Transfer Request Count.

By default I believe the 'size' property is set to 32768 (in bytes rather than samples), and the 'count' is set to four.  I would advise that your buffer size be set to at least the number of samples you're waiting for + the 'Data Transfer Request Size.  On Windows, I'd typically advise that you provide more buffer than that.

[josborne]

Hmmm.  OK, I tried that.  And my code still froze up at a random interval.  This time it froze up with only 387 available samples in the DAQmx buffer.

I am going to try and reproduce this issue using a very simple example.  Get back to you soon.

[josborne]

OK ... just a quick rant:

In general, I am quite dissapointed with using USB DAQ devices.  Its not NI's fault.  But from my experience, I just don't think that USB is made for doing any sort of DAQ tasks in the kHz range.  First, I struggled with onboard buffer overflows on the X-series USB devices that don't have deep onboard memory.  So I upgraded to the (expensive!) USB 6361 to get lots of onboard memory ... and now I am struggling with this weird freeze-up issue. 

But unfortunately, the form-factor of my solution prevents me from using a PCIe card.   If only NI made half-height PCIe cards!!!

[Mcdan]

If you can find code that can reproduce your freeze up, I'll be happy to take a look at it.  We have continued to fix problems as they've come up over the past few releases, so it's possible that upgrading to the newest version of DAQmx may help, but that's a shot in the dark.

I would recommend that you double check the USB port you're attaching to, and verify that it's a USB 2.0 High Speed port.  We have seen bad behavior with some USB 3.0 ports and bandwidth is limited on 'full speed' ports.

In an earlier post, you'd mentioned that you had a USB hub attached to the computer.  Do you have other USB devices in your system?  Might they be competing for bandwidth?

I really haven't seen/heard of the behavior you're describing, so I don't have much else for you to try at the moment.  I'll post back if I can think of anything else.  Again, if you can find a way to reproduce I'll certainly have a look at it.

Dan

[josborne]

Thanks again, McDan.

We have covered a few different issues, and I think I now have a solution (or workaround) for all of them.

And I think I may need to eat my words.  I am beginning to suspect that my "AI freeze" issue is actually related to your orignal suspicion about the buffer sizes. 

To make things more complex, my application actually uses a reference trigger as a stop trigger for the AI task.  To do that, I follow this example.  Its a bit confusing because you need to setup your acquisition as a FINITE acquisition, even though it is NOT finite.  It is continuous until the reference trigger is received.  I think I can then randomly end up in a weird race condition where my DAQmx task thinks my acquisition is complete.  So it stops filling the buffer.  This seems to happen even when I make the buffer really huge (30 seconds worth of data). 

In any case, I have removed the reference trigger, and things appear to work better.  I will let the system run over the weekend.  If it hasn't frozen up by Monday, then I know the problem is solved.

[Mcdan]

I'll see about running the referenced example this weekend and see if I see any strange behavior.  Is the condition where DAQmx thinks the task is done related at all to the arrival of the trigger signal?  Or can I run the example and never send a trigger?

Dan

[josborne]

Thanks, McDan.  I think you can try running the example and never send a trigger.  My AI task is freezing up before the trigger signal arrives. So I set it up to wait for a reference trigger, and just let it continue running.