0

What does a PCOUNT input that is set to accumulate pulses do when it exceed its 7 significant digits? 999999.9

Russell Gunn 3 days ago in IQANdesign updated by Gustav Widén (System support) 2 days ago 1

I am using a PCOUNT input that is set to accumulate pulses to calculate a very low frequency. I am using the count change over 10 seconds, so I am not interested in the actual count, just the change. It is not difficult to deal with a roll over that a hardware counter would experience without losing an accurate delta, but I do not see any indication that the PCOUNT rolls over or how it behaves when it exceeds 7 significant digits. I.E. 999999.9 (a decimal is needed since the counter increments by 0.5 on the rising edge and another 0.5 on the falling edge of a pulse) This seems like a big number but a 20K Hz input would exceed this every 45 second. (This could cause problems if using two counters to capture the differential of drive track position counters at high speed)

I have my application mostly working by resetting the counter, but because the PCOUNT channel does not support an internal reset capability like an event counter channel. The reset must be initiated by external logic, which does not play nice with the pulse inputs and appears to miss pulses during the reset.

This is probably complicated by the fact that the counter increments by 0.5

I may be able to make this work using the input in the non-accumulate mode and summing it in a math channel where i have more control when I reset the value.

The PCNT will continue to accumulate, but as the channel value is a 32-bit Real, you may not see a change of the channel value until the accumulated change is large enough. 

Internally the counter is a 32-bit signed integer, and it is counting both positive and negative flanks (That is why you see counter increment by 0.5 for one pulse).  

For this reason you need to stay below 1*10^ 9 pulses.