DO task randomly stops (no errors generated)

[Joseph_Loo]

By any chance did you put in the windows xp hot fix on USB. Only applicable if you are on windows xp.

[josborne]

Ah, ha!  Kudos to McDan for suggesting to add the "Done?" property.  I did this (see attached snippet) and now I suddenly get an error message with some useful info! 

Hmmm.  Not sure if I'd call this a bug, but you would think the DAQmx Write Propery Node should also generate an error if the task has failed due to error.

[josborne]

And this is the error I am getting:

Error -200290

The generation has stopped to prevent the regeneration of old samples. Your application was unable to write samples to the background buffer fast enough to prevent old samples from being regenerated.

To avoid this error, you can do any of the following:
1. Increase the size of the background buffer by configuring the buffer.
2. Increase the number of samples you write each time you invoke a write operation.
3. Write samples more often.
4. Reduce the sample rate.
5. Change the data transfer mechanism from interrupts to DMA if your device supports DMA.
6. Reduce the number of applications your computer is executing concurrently.

In addition, if you do not need to write every sample that is generated, you can configure the regeneration mode to allow regeneration, and then use the Position and Offset attributes to write the desired samples.

Task Name: _unnamedTask<4B>

[Ben]

---

@josborne wrote:

And this is the error I am getting:

Error -200290

The generation has stopped to prevent the regeneration of old samples. Your application was unable to write samples to the background buffer fast enough to prevent old samples from being regenerated.

To avoid this error, you can do any of the following:
1. Increase the size of the background buffer by configuring the buffer.
2. Increase the number of samples you write each time you invoke a write operation.
3. Write samples more often.
4. Reduce the sample rate.
5. Change the data transfer mechanism from interrupts to DMA if your device supports DMA.
6. Reduce the number of applications your computer is executing concurrently.

In addition, if you do not need to write every sample that is generated, you can configure the regeneration mode to allow regeneration, and then use the Position and Offset attributes to write the desired samples.

Task Name: _unnamedTask<4B>

---

Which makes me question the USB again (since the PCI worked fine).

Question out loud:

Does the new version of NI Spy allow monitoring of USB devices?

Maybe wort h a look lacking other ideas.

Ben

[josborne]

So now I am wondering how to get around this error.

This page has some useful advice.

I have a USB-6366 which has deep on-board memory (supposedly has 32 megasamples).  But If I set "UseOnlyOnboardMemory = TRUE" as suggested in the above KB article, I get this error:

Error -200341

Generation was configured to use only onboard memory, but the corresponding buffer is larger than onboard memory. Buffer size is provided implicitly when data is written or explicitly when the buffer is configured.

Configure the generation so that the Use Only Onboard Memory property is false. Alternatively, you can make sure the number of samples written and/or the size of the configured buffer do not exceed the onboard memory size.

Onboard Memory Size: 2047
Required Buffer Size in Samples: 6000

Task Name: _unnamedTask<56>

I find that a little strange.  I only have 2047 samples of onboard memory?  I guess the 32 MS spec only applies to AI tasks?  Hmmm...

[josborne]

I'm going to great a support request for this issue because I am also getting bizarre behavior on my AI task.

[Mcdan]

Let me address a few of your replies:

I agree that it's a bit strange that querying certain properties do not return errors.  It's one of the things that I occasionally forget.

The deep memory is used for AI FIFO, and cannot be distributed among the other subsystems on the device.

Like Ben, I'm curious about what type of USB port you are attaching your devices to.  Can you confirm that you're attached to a USB 2.0 high speed port? This would show up in device manager as a 'USB Enhanced Host Controller.'  You're not by chance using a USB 3.0 port are you?  We've seen some issues with that.

Can you describe your bizarre behavior with AI?  I'd be happy to try to reproduce other bad behavior if I can.

Dan

[josborne]

Thanks!  I'll take a look at the USB port and get back to you with the details.  I do have a USB hub attached to the PC which might be messing with it (though my USB-6366 is attached directly to the PC).

I guess I can accept that querying certain channels does not generate an error (especially since I know about it now!). 

Sorry to hear that the onboard memory is only for AI.  But I think I can work around this DO issue anyway.

Regaridng the AI issue:  I created a separate email support case for that issue the other day.  See attached VI that demonstrates the problem.  After 1 second, the AvailSampPerChannel stops incrementing.  But the task is still acquiring data because it will eventually generate an error when the onboard FIFO fills up after about 30 seconds.

[Mcdan]

I think what's happening here is the amount of data that you're waiting for is exactly the same as your buffer size (by default buffer size from sample rates from 10 k S/s to 100 k S/s is 100 kS.  Can you wire 200k to the 'samples per channel' input to the DAQmx Timing VI?

Dan

[Mcdan]

Missed the edit window on my last post.

I messed up the default buffer size information... I should have said that for sample rates from 10 k S/s to 1 M S/s, DAQmx will default to a buffer size of 100 k S/s.  This information can be found by  searching the DAQmx help for  "How Is Buffer Size Determined"