problems with asynchronous acquisition and traditional NI-DAQ

[-kb]

hi,

Yes, cool. This does make it so that I can start reading right away, and my results match up close to yours. But...

Unfortunately, this seems to introduce a lot of random delays. The reason why I was interested in reading data continuously in the first place was because I had been reading data with SCAN_Op() in the Traditional NI-DAQ, and every 10 seconds (+/- 30 msec) that function would spontaneously take twice as long as normal. I need to have a constant loop rate, so this hic-up was not acceptable. I thought the delay was somehow related to the Scan_Op() function. Hence the switch to working with DAQ_Monitor() and DAQ_Check() and subsequent problems with acquiring the most recent samples.

What's happened now, unfortunately, is that even though we've acquired the most recent samples and we're acquiring data continuously, I'm still getting a hic-up every 10 seconds during the call to DAQmxReadAnalogF64(). And, actually, the loop timing appears worse with the Data Transfer Request Condition set than with it not set.

Though it took some time to get the hang of it, I think I have the code working by registering an event. It writes 50 pts to a buffer every msec and computes the average. All I do in my main loop is query the average to get my reading, and my data is at most 1.5 msec old. I still get a delay every 10 sec, but this happens outside the loop (not while waiting for a DAQ function to execute), and I have an interpolation scheme to deal with that situation.

I should be good to go for now. But, do you know what this delay every 10 sec could be related to? Is there any chance it has to do with the DAQcard? For the moment I've been assuming it to do with the Windows OS. Also, is there an analogous setting in Traditional NI-DAQ to the Data Transfer Request Condition in NI-DAQmx? Maybe why DAQ_Monitor() and DAQ_Check() counters wouldn't update is related to the data transfer settings?

Thank you for all your help, Jesse O. Take care.

-kb

[Jesse_O]

Hello -kb,

No problem, we are glad to help.  I have ran the code many more times, and increased the mount of time samples are taken.  I do see that there are times when it takes longer to return from reading the required samples.  In my tests, the return time did not increase every 10 seconds.  The return time would increase every 5-20 seconds then return to normal.  I believe this can be explained by the interrupts required to transfer the data from the PCIMCA DAQCard.

I ran similar tests on a PCI version, and there were times when the return time would increase, but not nearly as frequency.  The setup you have now might be your best option.

There are similar functions in traditional DAQ, however I would not recommend using them.  If you search the index of the Traditional DAQ reference help for data transfer mode you will find the calls.

Regards,

Jesse O.
Applications Engineering
National Instruments

[-kb]

hi again,

While we got the events working in the sample code, I've been having trouble integrating them into my simulation. My application uses the Win32 environment with DirectX. The performance I would like to achieve is a new sample (a new set of >10 points/channel) available every 1-2 ms. Initialization and everything seems to go fine until I enter the Windows message handling loop. After about three iterations of the loop, I'll get readings readings from the card for about 50 ms; and then all readings vanish. It's like the callback function isn't handled anymore. Then after about 3 s, the message "Loaded 'C:\WINDOWS\system32\nicesru.dll', No symbols loaded" comes up. And 1-2 seconds after that, the DoneCallback error comes up saying that events are generated too quickly for the driver to keep up. I think the DoneCallback error is a symptom of data not being read from the buffer, so I'm not worried about that. When I decrease my sample rate and sample size, I can keep reading from the card for a longer period of time; but the performance isn't close to what I'm going for.

I see using events as the low-level form of controlling when and how much data is transferred across the buffer and when (though, going back to our previous example ContAcq-IntClk-Modified_c.c, I tried setting the Transfer Request Condition to OnbrdMemCustomThreshold, but an error message popped up saying that it was "not a supported value for this property"). I would hope that there's gotta be some sort of happy medium between getting samples quickly and not bogging down or overloading the system too much.

Do you think I might be asking too much of Windows? Could there be other "tricks" to keep the event running? Any thoughts? Is there an analogous document for NI-DAQmx to Application Note 086?

Thanks again.

-kb

[Jesse_O]

Hello again -kb,

Acquiring data at a rate of every 1-2ms is fast for a windows system.  I am not surprised that at this data rate your application is having problems keeping up (especially since your DAQCard requires interrupts to transfer data). 

Does the status from any of your DAQ operations indicate any problems (i.e. buffer overflow)?  I would assume there is an overflow error since decreasing the sampling rate fixes the problem.  There is always a trade off between acquiring data from the device quickly and cpu usage.  Even why I setup a laptop with a DAQCard 6024, and running the example code I posted I was getting loop times of 10ms to 13.5ms (a 35% time increase). 

Unfortunately, I do not know of any other tricks to help your loop run faster.  Also, I could not find Application Note 086.  If you post a link to it, perhaps I can suggest something else.

Best of luck,

Jesse O.
Applications Engineering
National Instruments

[-kb]

hi,

Thanks for the response. Ya, none of the other DAQ operations indicate any problems other than towards the very end when DoneCallback says there's been an overflow. And as far as an overflow happening early on, I cannot see one.

The App Note I was referring to can be found at http://zone.ni.com/devzone/conceptd.nsf/webmain/159C194435C8CA5786256869005EF6AE?opendocument, called 'Using DAQ Event Messaging under Windows NT/95/3.1.'

An interesting finding yesterday, though - something I don't think I would have found had you not suggested going to NI-DAQmx and using events - is that the mouse on my computer produces a Windows message every 5 seconds (even though my simulation doesn't use the mouse). This was the source for one of the hicups in my loop. I've since restructured the loop so that a Windows message doesn't hang it up.

No worries if you can't find an updated App Note 086. Because asking for data transfer every 1-2 ms looks to be too much for Windows and my simulation, I think sticking with finite samples is the best way to go. I'll then use some interpolation if/when one of the samples takes longer to acquire than expected. Thanks again for your help. Cheers.

-kb

[Jesse_O]

Hello -kb,

I am not aware of an online article for DAQmx that discusses events in the same detail as the document you posted does for Traditional DAQ.  I have looked at the document you linked, and you can get almost the same information by combining the examples that ship with the DAQmx driver along with the NI-DAQmx Help File.

In the DAQmx help file if you select the index tab and type in 'events', you will see both hardware and software NI-DAQmx events.  This information combined with the examples that install with the driver is basically the same as the online resource you provided.

You are correct that any other interrupt on your computer will interfere with the performance of you DAQCard 6024 (even your mouse).  Also, another major item that can influence performance is sharing an interrupt.  I've seen in the past if your DAQCard shares an interrupt line with another device, they are competing for that line and your performance decreases.

Regards,

Jesse O.
Applications Engineering
National Instruments