Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Too long AI-read time for USB-6353

Solved!
Go to solution

Hi!

I am having some problems getting my NI USB 6353 to behave, so I am hoping someone more competent than me can explain what I am doing wrong.

Here is the situation: I want to start sampling one AI-channel during 1 ms after an external digital trigg signal goes high. I sample at a rate of 1MHz, and I take 1k samples.

You can see my little test-vi below. I check the time elapsed between start and stop of AI-read.

The external trigger goes high every 10:th ms (f_trigg 100Hz). The AI-read time should theoretically be 1 ms, with plenty of time to wait for the next trigger, 9 ms later. 

 

However, it seems impossible to get the AI-read time below 40 ms. Clearly something is wrong in my code, but what?

 

Trigg frequency 100Hz, period time 39 ms --> NOT OKTrigg frequency 100Hz, period time 39 ms --> NOT OK

 

I would be most grateful for any advice regarding this.

Thanks!

0 Kudos
Message 1 of 4
(2,670 Views)
Solution
Accepted by topic author fahrentorp

One tip is to use an explicit "DAQmx Start Task" before your loop. This moves the task state model to the "Running" state before your read. (By not having it, DAQmx Read will implicitly move it to Running, but now you're also timing the transitions through the Reserved and Committed states.)

 

Your use model (sample for a period of time after receiving a periodic external trigger signal) also sounds like it could be a good fit for a retriggerable task.

 

 

——
Brandon Streiff
ni.com/compactdaq · ni.com/daq
Message 2 of 4
(2,655 Views)

Adding to bstreiff's answer that I kudo'ed.

 

1. I agree with his advice to configure to be hardware-retriggerable, then start the task before the loop.   This assumes you want to capture 1 msec of data for each trigger that repeats every 10 msec.

 

2. Another use of the task state model he linked is to "commit" the task before the loop, then you can start and stop the task inside the loop with very minimal overhead.   Likely well below 10 msec.

    I don't think it's the best option for your particular app here -- when available, hardware-triggering will be better.   It's just something to keep in mind for future tasks where you have no hardware trigger but want low overhead for stops and restarts.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 4
(2,643 Views)

Thank you Brandon.

I had tried start-stop outside my loop previously, but failed. This produced a DAQ-error, but with the use of the Retriggerable property node when configuring my task, the AI-read now takes 6 ms. This gives me enough time to be ready for the next trigger puls.

Best Regards,

/Fredrik

0 Kudos
Message 4 of 4
(2,634 Views)