Will DAQmx read/write (USB bulk) generate error(s)?

[ocyj]

Hello forum

I have a setup where I use a NI USB-6218 to generate a low frequency sine-signal that is fed to a system of external transducers and then sampled on the same DAQ for further analysis. The general idea of the procedure is presented in the attached VI snippet.VI snippet

As you can see the size of the generated buffer and number of samples to be sampled is quite large. The AO.DataXferMech and AI.DataXferMech are both USB bulk in my actual application. The signals looks very good though and the results are looking promising so far!

Some questions I have:

• My concern is that the generated signal could get glitchy if the USB transfer process fails. Is it safe to detect this by monitoring for error -200361 as described in this article?
• If this error is reported, what VI would report it specifically?
• In this snippet the DataXferMechAX-properties are Programmed I/O. I wonder what could have caused it to default to that value when I inserted the flow to a single VI?

I'm very grateful for your responses!

Best regards,

Oscar

EDIT: I messed up with the "attached VI snippet" 

[NIRebecca]

Hi ocyj,

Could you confirm why you are using the "DataXferMech" functionality? DAQmx will handle the data transfer from LV to HW automatically. 

The Data Transfer Mechanism has limited values depending on the hardware and sample mode. For example Programmed I/O is the only value supported when the Sample Mode is Hardware Timed Single Point and typically used in Software-timed (on-demand) operations. 

[ocyj]

Hello NIRebecca, thank you for your reply!

I only use the "DataXferMech" to read its value (to see what DAQmx happen to choose).

My concern in that the buffer size (the array of generated sample points) is many times larger than the on-board buffer, so I assume that a continuous stream of data to the physical device must take place?

It is crucial for my application that any glitches in the output signal (which is a simple sine-signal) are detected. So my main question should maybe be formulated as is there a fail-safe way to pick up if DAQmx has not been able to keep up with the data transfer?

/ocyj

[GerdW]

Hi ocyj,

It is crucial for my application that any glitches in the output signal (which is a simple sine-signal) are detected. So my main question should maybe be formulated as …

The main question here is: why did you choose an USB device then in the first place?

When such things are "crucial" you always can choose other devices and other bus systems (PCIe, PXI)…

[ocyj]

Thank you for reply GerdW!

Are those bus systems typically not more expensive to acquire than the USB-base line? It's my understanding that one would still use the DAQmx interfaces when programming I/O-operations in LabVIEW. Are there specific functionality that makes detecting glitches easier with those systems, that are not available for USB-devices?

Like I said, the most crucial thing is detecting any problems in data transfer, so that any acquired data can be disregarded.

[GerdW]

Hi ocyj,

Like I said, the most crucial thing is detecting any problems in data transfer, so that any acquired data can be disregarded.

No, you were asking something different:

It is crucial for my application that any glitches in the output signal (which is a simple sine-signal) are detected.

What exactly do you want to detect: "glitches" in a signal or problems with data transfer?

So my main question should maybe be formulated as is there a fail-safe way to pick up if DAQmx has not been able to keep up with the data transfer?

When there is a problem within the DAQmx driver you will get an error message…

Are those bus systems typically not more expensive to acquire than the USB-base line?

Often those PCI(e)/PXI devices are more expensive. (I forgot to mention the RIO line in my first post.)

But then those devices offer (sometimes) more possibilities than USB devices.

Conclusion: you should select your DAQ hardware according to your measurement requirements…

Are there specific functionality that makes detecting glitches easier with those systems, that are not available for USB-devices?

Again: which "glitches" do you want to detect?

[ocyj]

Hi again GerdW, thanks for replying. I can see your point!

Naturally it would be preferable to detect any type of glitches, but to keep it practical, the most important factor to monitor for here are are discrepancies within the time domain (within the hardware's specified tolerance naturally), occurrences of types of buffer under/overflow etc. (Quantization errors and such will be tolerable as the 16-bit resolution of the USB-daq device is considered good enough).

You mentioned that the DAQmx driver will report error messages when problems occur, is there any approach that is considered good practice to check for specific errors as a mean to detect occurrences of buffer over/underflow (whenever the daq has not been able to "keep up" with the buffer array's samples so to speak!).

[GerdW]

Hi ocyj,

you can look up error numbers in the DAQmx help - or by playing with the error cluster (right-click to explain errors/warnings)…

This would be the easiest way to handle specific errors:

(The ClearErrors function in recent LabVIEW versions uses a very similar approach.)

[Kevin_Price · Accepted solution]

It can be hard to anticipate *all* the specific error #'s that *might* occur in the future.  Just be forewarned that using an approach that depends on a specific match, it'll be hard to be confident that you've got all the right error conditions covered. 

That said, you can at least recognize some easily-induced ones and provide some help text for those foreseeable errors.  For example, you can probably induce underflow errors on your continuous AO task by defining an extra-small buffer.  To force DAQmx to have a suspiciously small buffer, you'll need to set it up with a DAQmx Timing property node.  (The regular DAQmx Timing.vi will calculate its own idea of a reasonable sized buffer based on your sample rate when you specify Continuous Sampling.)

Your AI task is Finite so it might be harder to induce errors.  I'd set it up with the fastest possible sample rate, many seconds worth of buffer to fill, and then I'd do software-timed AO updates as fast as I could in a loop -- to keep the driver busy managing bi-directional bus traffic, and hopefully interrupting AI data transfer.

-Kevin P

[ocyj]

Hi Kevin! Thank you very much for your valuable feedback! I will try your approaches to see when/how the system breaksdown.