Error -201314 when stopping Counter Input task

[Ghost_coder]

I am trying to acquire a buffered 250Hz, once per second, measurement of a flow meter, or other frequency output device. So typically I wait until 250 samples are available, then read from the device.  My VI works when a signal is present, but if the frequency is too low, or stopped, I don't get any available samples, and it doesn't restart.  I would prefer to record 0Hz for that duration.  Only after I stop the task will it get error -201314: "Multiple Sample Clock pulses were detected within one period of the input signal. Use a Sample Clock rate that is slower than the input signal"

I would like to know before stopping the task if the counter is in this state, so I can clear the error, and restart the task.  Is there a property node I can read?  I have tried Daqmx create channel CI:Freq, CI: Pulse Freq.

[Kevin_Price · Accepted solution]

You would see that error on your Read attempt if you were looking for it.  Right now, all DAQmx errors are retained but ignored until you terminate the loop manually with the GUI stop button.  That's why you only see it after stopping the task.

Check for the error inside your Read loop, right after attempting to Read.

Two other tips:

- you're line to line on your Read timeout, which isn't really a great plan.  I'd always set the Read timeout to be longer than the nominal time, never exactly equal.  

- there are other ways to monitor frequency.  Maybe one of the others would end up being a better choice for this app, where the signal you want to monitor can be intermittent?

-Kevin P

[Ghost_coder]

Thank you Kevin,

Yes, when I do a read of 1 sample or more, I see the error.  I guess I expected the Read property node would also generate the error.  Thanks for the other suggestions too, I updated the timeout.

I played daqmx Timing Properties nodes, I get continuous samples when setting SampClk.OverrunBehavior = Ignore Overruns.  If no pulses initially, the value is INF.  Then, if I unplug the frequency sensor the last buffered value persists.  Although this will cause misleading data, it solves my acquisition issue.

Is there a way to tell if its in this mode, and actively ignoring overruns?

[Kevin_Price]

I've done a *lot* with counters, but I've never used the relatively newer capability for frequency sampling at a constant rate.  I'm afraid I have no particular insights for that measurement mode.

I most typically use the 1-counter method that uses Implicit Timing.  That has a few gotchas to watch out for too though. 

In your case, I think I'd try changing from Freq measurement to Edge counting.  Right now you iterate at about 1 Hz, and average down your 250 measurements to a single effective sample.  If you switch to Edge Counting, you could just run your sample clock at 1 Hz and get the same info.

(I don't think you'll run into issues with a property known as "Duplicate Count Prevention", but if you get a different, complicated-sounding error, search on it.)

-Kevin P