DAQmx does not use Windows interrupts???

[fox14534]

One of my engineers told me this and I even had NI tech support tell me this but I still don't believe it. When the DAQmx driver wants to get data from an NI DAQ board it sets up a loop, in Windows, and polls the board. It polls? It doesn't use interrupts? This seems so hard for me to believe that I would just like confirmation on it one more time before I give up on the idea.

Here is what I would like to do. Suppose I want to monitor 5 input lines on the DAQ board. When any of these lines changes I want the DAQmx driver to trigger an event or fire a callback into my code. But, I don't want the driver to set up a thread that spins and polls the DAQ board for these changes; that is a waste of Windows CPU time. It seems to me that the driver should be able to have a thread in a wait state until it is interrupted by the DAQ board. Is what I want to do possible?

Thanks,

Peter

[Quantumbyte]

Peter,

Let me clear up some confusion. There's a difference between continuously polling the board in order to transfer data and continuously looking at the data coming in to determine when it changes. Data transfer between the board and your computer memory can be set up to use interrupts or DMA. In either case, the transfer will begin when there's enough data available and will stop when there's not. This will not rely on polling in any way to determine the status or transfer the data. When using interrupt mode we do use interrupts to tell us when there's data available. When using DMA that is no longer necessary. In either case, we never continuously poll the device for data.

When you call read in LabVIEW, and request a number of samples greater than the number of samples available, we have to check the computer memory to determine when such number is available. By the default we will check and then yield to ther processes, to reduce our CPU usage, however, you can set that up manually by setting the wait mode in the read property node. Depending on the DAQ product and task configurations, other available options could be polling and interrupts. Again, this is only within the computer's memory and not with the device.

On the other hand, there's the matter of observing the data and wait for changes in it. What you're requesting is to start your acquisition when an analog input changes. Current DAQ boards offer up to one analog trigger, so you could acquire your 5 signals when one of them changes, but not when any of them changes. For that you'd have to rely on the CPU. On the other hand, with a little external circuitry you could add your 5 signals into a 6th one that would be your analog trigger, and then you'd set up an acquisition of 6 channels, one of which would be the output of such a circuit. Still, you're left with the issue of how many samples you want to acquire every time the inputs change, and how soon after you finished acquiring them you need to be ready to detect changes again. If you need to watch the signals continuously without interruption and always be ready to acquire a set number of samples every time the inputs change then you need to acquire continuously and have labVIEW remove the uninteresting samples for you.

I hope that helps

Daniel D.
Staff Software Engineer
Multifunction DAQ

[fox14534]

Daniel,

Thanks for trying but I am still missing it. Perhaps you can address my exact application., I am not reading analog channels and I am not using LabView.

I am writing an application in Visual C++. I have the DAQ board on the PCI bus. Five switches are connected to five digital I/O lines, setup as inputs, on the DAQ board. My application wants to know when these switches change state (example, door #1 open). Ideally I would like to establish five callback routines, one for each switch. My callbacks would fire when their associated switch changed state.

If I use the DAQmx API to set up tasks, channels and callback routines, my understanding is that the DAQ driver will use one or more threads on the Windwos side, to monitor, in a polling fashion, for changes in the five switch lines. This seems wasteful of CPU time. I would have thought that your driver could have a thread be blocked waiting for an interrupt that tells it when a switch has changed and then it would call my appropriate callback. Is there a way to do what I want to do?

Thanks again,

Peter

[Quantumbyte]

Peter,

All right, so you're using digital. What DAQ device do you have? M-Series devices and some digital devices provide you with change detection on the digital lines. In a change detection task, the device will interrupt when any of the lines changes. You can then register a callback with the Change Detection Event (this is all supported in our c api through the DAQmxRegisterSignalEvent call).

Daniel

[fox14534]

Daniel,

Yes, I am using an M series board - the PCI-6229.

My understanding is that if I set up a task to monitor a change on an I/O line (setup as an input) then your driver will use a thread on the Windows side to poll the line for changes. Is this correct? Are there any other options as I would rather not have a thread doing polling on the Windows box?

Thanks,

Peter

[Quantumbyte]

Peter,

As I explained earlier, when you call read on such a task then we start polling the computer memory waiting for the data to arrive. We will yield to other processes to avoid hugging up your CPU, but we will definitely not hand there polling the hardware. As long as you don't call read, then there is no polling going on.

By registering a callback with the Change Detection Event as I suggested in an earlier post, and calling read within that callback, you are guaranteeing that polling is kept to a minimum, since you only check the host memory once you know a change already happened, and the information about it is on it's way.

Greetings

Daniel D.

Multifunction DAQ

[Jonathan_Brumley]

Hi Peter,

If you are concerned about how much CPU utilization the DAQmx driver uses, then why don't you test it out?  The Windows Task Manager will tell you how much CPU utilization your data acquisition task is using. 

We have designed DAQmx to maximize streaming performance while still minimizing CPU utilization.  However, if you are seeing a problem that we have missed, then please let us know about it in this thread. 

-- Jonathan