Simultaneous Analogue and Digital input using C DAQmx on USB-6353

[DavidSummers]

We are using a USB-6353 to simulataneously sample a digital and analogue input. The clock (~75kHz) is externally provided, and wired into PFI0. We are reading the input via the DAQmx library, which we access from C.

Now the problem is, that whilst I can access either analogue or digital, when I try and access both  after 20seconds or so I get the error:

DAQmx Error: The application is not able to keep up with the hardware acquisition. 

Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem.
Property: DAQmx_Read_RelativeTo
Corresponding Value: DAQmx_Val_CurrReadPos
Property: DAQmx_Read_Offset
Corresponding Value: 0

Task Name: _unnamedTask<0>

Status Code: -200279

Example code that gives this is attached.

Now when reading either analogue or digital, the machine isn't stressed, e.g. we'll below 50% loading. So there should be enough resources to read both analogue and digital at 75kHz.

So what am I doing wrong? I've tried defining both clocks as /Dev1/PFI0, or with one as /Dev1/ai/SampleClock; makes no difference.

Any ideas anyone?

[NASmith]

Hi David, 

I'm not very familiar with text based programming, but as the DAQmx API is the same, I can troubleshoot the error with you. 

Basically the error you are recieving is caused when the buffer for acquisition is filled up faster than samples are removed from the buffer to be read by the user. The error is caused when this buffer get full. 

To solve this there are a few things you can try:

1. Acquire data at a slower rate

2. Increase your buffer size. (increase samples per channel in DAQmx timing function)

3. Read data out of buffer faster. 

4. Overwrite unread samples - in labview this can be set from the DAQmx Read property node

I hope this helps, 

Regards, 

Nathan

[DavidSummers]

Yes the DAQmx set up I think is very similar via the C library as via lab view.

We can't easilly lower the aquistion rate, thats the rate of the digital system, and if we clock lower we would loose bytes ...

... however don't think that is the issue. Given that I can run either the digital, or anagule system (but not both) at less than 50% cpu load, and that is with all other logging enabled, suggests I should be fine with both running. Indeed the data up until when the error occurs, looks fine, suggests that I'm reading the buffers without a problem typically for ~5seconds or so.

So it seems almost as though running the analogue and digital system at the same time, and although I'm reading the data - it isn't emptying the buffer.

Problem with making the buffer bigger - is I basically read just one (or a few) samples from the buffer at a time, and then process in real time, so this wouldn't stop the buffer over flowing - just delay the overflow.

Is there any way of logging how much data is in the buffer?

Thanks,

David.

[NASmith]

Hi David, 

The below link describes how you can configure the hardware buffer using the DAQmx API. In addition, the related articles at the bottom of the page have some information which may be useful to you.

 I was checking the specification for the USB-6353 and it states that the digital input onboard clock (which is specified in your attached code) is configureable 0 to 1 MHz, system and bus activity dependent. Could the problem be caused by having too much bus activity on the USB-6353?

The below article may be of some use to you. If you have LabVIEW available to you, you could test this theory out with the VI linked at the bottom of the article.

http://digital.ni.com/public.nsf/allkb/4BBE1409700F6CE686256E9200652F6B

If I set my sample rate too high or my # of samples to read too low, I can recreate the error you are seeing. 

I don't think the issue is with the resources available on your pc. I think the problem stems from the buffer on the DAQ hardware becoming full. 

Let me know your thoughts. 

Regards, 

Nathan

[DavidSummers]

For us the clock in provided of PFI0, it comes in from the digital system, and is running at 75kHz.

Now using PFI0 as the clock seems to work fine, as we have a pattern of bytes transfered with a regular pattern (first few bits go 0-->1-->2-->0-->1-->2 repeating) - on demultiplexing the bytes we see the right series; and the rest of the data looks fine.

So the USB-6353 seems to be correctly reading the channel into its buffer from the external clock.

So problem seems in reading the data from the board via USB onto the attached PC.

Now the "while (1)" loop in the code runs as fast as possible, but it blocks in two functions:

DAQmxReadAnalogF64

DAQmxReadDigitalU32

Both of these should block on the same clock, so when one is unblocked the other should automatically unblock. As this loop runs as fast as possible, it should unblock as soon as data is in the buffer. Now as I read 1 bit of data from the buffer (second parameter) this should shorten the buffer by 1 sample, both on angloue and digital, in quick sucession. As the loop has no other delays, it should rapidly empty both analogue and digital buffers, as they should both have the same amount of data, as both are clocked of the same clock (PFI0).

Suspect I need some more diagnostic code, on how full the buffers are - I'll try writing that.

Yes we have other machines here with labview - so may check the same behaviour there. Can't easilly do this on the main test bench though as:

1) Doesn't have labview installed

2) I do need to do some process in the loop (e.g. unpack the digital data), and that easilly done in C.

Thanks,

David.

[NASmith]

Hi David, 

Have you managed to make any progress with your DAQ application?

Is there anything else I can help with?

Regards, 

Nathan

[DavidSummers]

Hi Nathan,

Sorry for delay - been off on leave for the last week.

Hadn't made any progress before I left - e.g. code still falling over.

Need to check the DAQmx documentation carefully - to see if I can probe how the buffers are behaving, e.g. obtain a smoking gun for if my code is as fault, or something in the DAQmx library.

I'll post more info to this thread when I get it.

David.