From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Time out even though a measurement is made for pulse width

CT,

 

I need to fix a typo in my response.  It wasn't 1 sample per SECOND or 2 samples per SECOND.  It was 1 sample per CHANNEL and 2 samples per CHANNEL.  Setting the timing to Implicit/Finite with 2 samples per CHANNEL gave me a pulse width reading without the timeout error.

0 Kudos
Message 21 of 24
(280 Views)

To VicL:

 

Welcome to the hardware forums.  Good job finding a workaround, let me help you out with a little more explanation about some things.

 

1. The best way to take 1 single measurement with DAQmx is to *never* call DAQmx Timing at all.  DAQmx Timing is used to reserve a buffer and set up a sample interval clock, neither of which is particularly useful if you're only taking one measurement.

 

2. As you found, DAQmx insists that if you *do* set up a buffered task, the buffer size needs to be at least 2.  This is a subtle hint at the same thing -- if you don't want to take at least 2 measurements then you also shouldn't be calling DAQmx Timing to configure a buffer and sample clock.

 

3. As you also found, when you *do* set up a finite task for 2 measurements, you're  still allowed to read only the 1st one.  Not typical, but it is allowed.

 

Go ahead and give it a try.  Take out the call to DAQmx Timing entirely and you should see that it works just fine that way too.

 

 

-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).
0 Kudos
Message 22 of 24
(269 Views)

Kevin P,

 

Thanks for your reply.  I had started my code without the DAQmx Timing VI and was getting the timeout error.  I tried implementing delays before and after starting the task.  I setup my hardware to send two pulses.  The two pulses would complete and then the timeout duration would finish running and I would get the error.  Nothing would get rid of the timeout error.  I even updated the DAQmx drivers with no change in results.  Then in my "Google" search I found this post, but still no resolution.  Only when I added the DAQmx Timing VI requesting 2 samples per channel did the timeout error disappear and the measurement worked as expected.  

 

Thanks again,

 

VicL

0 Kudos
Message 23 of 24
(255 Views)

To keep things clear for others who may come across this thread:

 

- what DAQ device were you using that gave you timeout errors whenever you didn't include the 2-sample DAQmx Timing call?    The shipping example "Counter - Read Pulse Width and Frequency (On Demand).vi" works fine for me with an X-series 6321 board.

 

- Can you post the code that produced timeout errors?  It'll be helpful to back-save to, say, LabVIEW 2016

 

- How did you manage the timing between when you requested the on-demand measurement vs. when the pulse(s) were actually generated?

 

 

-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).
0 Kudos
Message 24 of 24
(248 Views)