Peter Nachtwey said:
In my example I used 10 millisecond increments. I agree that 1 millisecond resolution would be better but resolution isn't the problem.
Lose milliseconds? Yes, if the time between pulses is greater than 655.35 seconds then the timer will overflow. How do you fix this?
In a/b machines, the timer ACC can overflow the PRE. If the timer is updated and has overflowed by more than 1 (of the units chosen), the ACC will be larger than the PRE.
Peter Nachtwey said:
The simple thing to do is to say the rate is 0 when the timer overflows. This isn't the main problem.
For this exercise, you may not need those milliseconds in your rate math, but
if the PLC he is using has a similar problem and does not store any overflow for use in the math...
If it took 1.02 seconds to make the part, and you measured it as 1.05, then reset the timer (kinda like resetting an encoder in motion) you will lose 30 milliseconds of accuracy...
No big deal, the resolution is there. In applications like shift production projections, that error gets amplified.
In a/b machines, to prevent that error, I don't reset the timer, I just turn it back a known amount, and put the preset at a value it will never reach.
Peter Nachtwey said:
No filtering is needed. Isn't my example with 1 reading and 10 millisecond resolution enough to prove that?
Yes, but he has a real problem with stability and/or accuracy.
So he is getting bad input data (garbage in/garbage out), or doing the math with imprecision.
My guess is that his pulses are not being picked up correctly in the first place (garbage in). Lately, though, my guesses aren't so good...
Paul