Continuous analog output intermittently dropping

[sambady929]

Yes, it appears on multiple computers with the same hardware running Windows 10. The ramp drops out randomly but the chance of it dropping increases with sampling frequency.

[Johnnyg17]

1) To be clear, when you're talking about "running the cards at the rated max of 1250 kHz", are you saying both your output and input task sample rates are running at 1.25 MS/s?

2) Which USB DAQ card is doing analog input and which is doing the continuous output?

3) When you said " I've been monitoring the USB and haven't seen any interruptions with it but I might not be using the best tools to look at it." what "tools" are you using? Moreover, are you judging the "dropping" of samples by viewing your analog input task?

4) It sounds like the signal you are trying to output is a ramped pulse train (to control a laser I believe you said). Is this correct and if so, are you using a continuously regenerated analog ouput task? (see here: http://www.ni.com/product-documentation/3874/en/)

4a) If you are generating a continuous and periodic waveform, what is the resulting signal frequency you are trying to obtain?

Let's also talk numbers:

Only your USB-6251 card is rated for the sampling/output speed of your "maximum" task frequency (manual here: http://www.ni.com/pdf/manuals/375213b.pdf). The maximum sample rate for a single channel analog input is 1.25 MS/s (equivalent to 1250kHz sampling freqeuncy) and the maximum output rate is 2.86 MS/s (which should be more than enough for outputting a waveform where you would like an output sample/update frequency of 1500kHz).

On the other hand, your other USB-6221 card is too slow for your given task (manual here: http://www.ni.com/pdf/manuals/375303b.pdf); the single analog input channel max sampling rate is 250 kS/s and the max update rate for an analog output channel is 833 kS/s. 

[sambady929]

1) The input sample rate is 1250kHz

2) The 6251 is both synchronously outputting and sampling at the same clock frequency. The 6221 just maintains a slew of variables.

3) I'm using the Windows built in Performance Monitor and logging USB data faults and transfer speeds

4) Correct. I'm not sure but I think it is continuously regenerated.

We also tried using a 6366 instead of a 6251 because it has a higher maximum frequency, and that also was failing even at 1250kHz

[Alex.W]

If you drop the sample rate to 1000kHz or 625kHz do you see the same behavior?

[sambady929]

At about 1100kHz and below, the issue does not occur for either card

[Johnnyg17]

Out of curiosity, can you go into more detail of your laser application and why you need to sample and output at 1250 kHz?

As well, the Windows performance logging tool that you are using to measure USB faults might give an indication to other processes/services trying to access the bus/memory/disk that could cause an error; for example, if you have a background program/service that periodically writes to USB (or even disk) or uses a lot of RAM, Windows will have to schedule that processor usage as well as share memory bandwidth with that process. And if you take into account that your USB bus is already pushing it's limits by having continuous bandwidth usage of 40 Mbit/s (1 output and 1 input task each doing 16-bit samples @ 1.25 MS/s), any interuption in the data flow process (again any jump in usage across USB bus or memory) could cause a fault that you are seeing; the only way to eliminate this factor is to make sure no other processes are running except your laser control application.

On the topic of maxing out your USB bus (what I think the real issue is), the USB 2.0 specification is rated for a theoretical max signaling rate of 480 Mbit/s but the effective max throughput can sometimes be as low as 35 Mbit/s (or even lower, depending on device factors); see here for USB 2.0 spec http://sdphca.ucsd.edu/Lab_Equip_Manuals/usb_20.pdf. This may explain why running at 1100 kHz and below works without issue as it may be a bus system limitation; the operating system, USB host controller and even USB cable can all factor into the max effective USB throughput that your specific system can achieve.

[sambady929]

We're driving a laser to sweep across a narrow range of frequencies by outputting a waveform to it. The input samples the signal from the detector. That's about as far into detail as I should go.

I've tried disabling various processes that may interfere with USB transfers and noticed no difference. To reiterate, this operation worked without issue on an older, slower computer from ~2011 so I highly doubt it has to do with speed.

[sambady929]

Update: I installed Windows 7 on the computer and that didn't solve it, so I believe it is a hardware issue.

That being said, the assumption we made was that the computer sends the waveform once, the NI card loads it into memory, and then constantly outputs that. Instead what we've found is that the computer is resending the waveform every cycle, and every now and then there's a glitch where a string of 0's is sent, which is where the problem happens.

Looking at the code I posted earlier, is there a modification I can make that would allow the computer to send the waveform once and then have the card handle it from thereon after?

[Johnnyg17]

That sounds like it very well could be the source of your issue. What you're looking to do then (write waveform/ramped-pulse to buffer once and keep outputting) is called Analog Output Regeneration in DAQmx world. I posted a link to an article about it in a previous post but here it is again: http://www.ni.com/product-documentation/3874/en/

This is most likely the function you are looking to use in .NET to set the regeneration property http://zone.ni.com/reference/en-XX/help/370473H-01/mstudiowebhelp/html/218c72d8/

[sambady929 · Accepted solution]

Issue has finally been fixed. We used a simple line of code that allows the computer to send the waveform once and then lets the card keep it on memory and takes care of it until told otherwise.

Call DAQmxSetAOUseOnlyOnBrdMem(AOFastHandle, "Dev" + Trim(Str(Sys.FastBoardNum)) + "/ao0:1", True)

Now that there's no interaction between the USB port and the card, everything works perfectly. For reference, the processor is the Celeron J1900. There may be some sort of hardware incompatibility between it and the 6251.