How to read a ctr when counts can be zero?

[DieselPower]

That is a helpful explanation.

Now how am I supposed to read RPM when the pulses go to zero?  Do I need to change from a frequency measurement to a counter measurement?  If I simply read the count at fixed intervals it won't complain about a count that isn't changing, right?  I'd just need to be certain that the count intervals are deterministic.

[Kevin_Price]

Instead of configuring for direct frequency measurement, your situation seems like a fine candidate for buffered edge counting at a constant sample rate of 10 Hz.  Then you'd take a finite difference of the count values divided by 0.1 sec to do your own frequency calculation.

Generate the 10 Hz clock with one of your other counters, configure your buffered edge-counting task to use it as a sample clock, and start the 10 Hz clock task *after* starting the edge-counting task.

In this mode, getting no pulses just leaves the count value the same, giving you a finite difference (and therefore RPM) of 0.

-Kevin P

[DieselPower]

Is it possible to reset the counter programmatically?

Otherwise it is going to roll over and I'd just have to check if this count < last count and then account for maxcount - last count + this count = the actual count.

[Kevin_Price]

There are a lot of possible answers to this and I don't have 100% confidence in my memory or the hardware needed to test some of them out.

- you can't make a software call to reset the count while the task remains active

- I *think* that if you read the encoder angular position as a DBL, DAQmx will manage both the pulse-per-rev scaling *and* these kinds of rollover issues for you.  Not 100% sure though.

- There are also ways to make use of casting between signed and unsigned 32-bit ints that can help.  This is simpler for cases where the count is always increasing.  One example of a thing that helps in either direction is to cast from u32 to i32, then look for a sign change between consecutive count values.  (In this situation, treat 0 as positive.)

- your little algorithm can work too, though you need to extend it to account for rollover in the decrementing direction

- there's a DAQmx property related to "terminal count" that can be queried to detect rollover.  This probably won't help all that much when you're doing a buffered task because you can't automatically identify the sample where the rollover occurred.  And then you have to resort to one of the other methods anyway.

I'd probably test whether DAQmx does indeed handle things properly when you read DBL angle values and if not, revert to an extended version of your algorithm.  You already have an understanding how to do that, so no particular learning curve, and the code execution will take negligible time.

-Kevin P

[DieselPower]

The counter should always be counting up, right?

[Kevin_Price]

Sorry, I think I got mixed up with another thread I've been in that involved angular encoder measurements where reading as DBL might be useful and where counts might increment or decrement depending on the direction of motion.

For your edge counting task, yes the counts will increment by default.  You'd have to go out of your way to configure the task to make it decrement instead.

-Kevin P