Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Measuring Frequency from Multiple Inputs with One counter X series Daqmx

I am attempting to internally mux my Daqmx to read a sample of frequency from 8 input pins.

My current method works but it is slow. 500ms to read 8 channels.

 

However when I have the rest of my Tasks running on my daqmx 6343 the time it takes to read 8 channels jumps up to 2000ms.

Theoritically since i have a 30 ms time out on my read  it should take

 

(30ms time out + 5ms read/write/time/jitter) * 8 = 280 ms aproximatly

 

Why am i getting such bad performance on this task?

 

11-13-2013 1-14-11 PM.png

0 Kudos
Message 1 of 5
(3,778 Views)

You must be on a USB-6343 (as oppsed to PCIe).  The constant reconfiguration of the device across USB is causing the loop to run slowly (I'm not sure what the rest of your tasks are doing, but if it involves continuously transmitting data across the bus then this would add to the latency as multiple resources are competing for the same bandwidth).  I suspect that you would be slightly better off by configuring multiple tasks and switching between them compared to reconfiguring a single task multiple times.  The best improvement however would be to switch to a bus with lower latency like PCIe.

 

 

Best Regards,

John Passiak
0 Kudos
Message 2 of 5
(3,768 Views)

I don't have a USB X Series available to validate my theory about multiple tasks vs. reconfiguring a single task, but I ran this benchmark on my PCIe-6351 (ctr0 is generating a 20 MHz pulse train in all cases--I kept my source frequency high to try to isolate the overhead of reconfiguring/switching tasks):

 

 

Reconfiguring a single task (similar to what you are doing now):

 

SingleTaskReconfigured.png


2.1 ms per loop (or ~1 ms per channel).

 

 

 

Switching between tasks:

 

MultipleTasks.png

 

0.69 ms per loop (~0.35 ms per channel, roughly 3x faster than the first benchmark).

 

 

Keep in mind that my benchmarks were only checking for overhead and I was measuring 20 MHz signals to minimize time spent waiting for a sample to be present.

 

 

I'm not sure exactly how this will translate to a USB X Series, but as the overhead is likely order(s?) of magnitude higher than on my PCIe card I'd expect it to be worth your while to try configuring multiple tasks rather than reconfiguring a single task.  You could also look at your other tasks and see if they could be optimized a bit--it seems they are introducing quite a bit of overhead.  If you need to be able to reconfigure the device more quickly I would consider a PCIe replacement for your DAQ card. 

 

 

Best Regards,

John Passiak
Message 3 of 5
(3,762 Views)

I assume when I switch the pin and read it actually calls the Stop and Start.(aka there is alot more overhead than expected)

 

Im curious if i could use the signal routing pallet to get a speed boost on these operations. Have one pin reading frequency and muxing the inputs to it that is.

0 Kudos
Message 4 of 5
(3,759 Views)

Yeah, it actually calls start and stop when you call the read.  If you weren't switching the pin (or task) you'd want to explicitly start/stop outside your loop, but since you're switching the pin, it doesn't make any difference as you'll need to stop before switching the pin anyway.

 

 

When the task is running the terminal you need (in this case, the gate of the counter) is reserved, and trying to connect to it via connect terrminals will return a "resource reserved" error.   You could do something like this:

1.  Signals connected to PFI0:7

2.  Use connect terminals to route PFI0:7 to PFI8

3.  Physically wire PFI8 to PFI9 (use PFI9 for your frequency measurement)

 

The problem is you have to call disconnect terminals as well (to free the route up for the next loop iteration).  I found that on my PCIe Device it takes about as long as configuring multiple tasks (I didn't actually wire this up, but I think below gives a good representation).

 

 

Using Connect/Disconnect Terminals:

 

ConnectTerminals.png

 

0.68 ms per loop

 

 

 

That got me thinking though...  If you used a digital write with an external MUX you can probably get better results:

 

 

Digital write to control external MUX:

 

DO_Write.png

 

0.04 ms per loop (about 16x faster than what I've benchmarked so far).  In reality you'd also have to have some additional delay after toggling the DO line to guarantee that the MUX has switched before taking your counter reading.

 

 

 

You might want to try a benchmark like this on your actual hardware before you set everything up to find out that it doesn't give the result you need.  These PCIe numbers give you a relative approximation at best, but might not be indicative of what you'll see on a USB device.

 

 

Best Regards,

John Passiak
0 Kudos
Message 5 of 5
(3,751 Views)