The is a function you can use to set what the FPGA sees as stopped. its the setMinRate function.
In the Encoder class it’s called setMinRate, in the Counter class it’s called setMaxPeriod.
Sounds like the answer to our problems.
I imagine that we don’t want to use the stalled feature at all. Is there a downside to setting the max period to a high value? e.g. 6 seconds period is equivalent to 10 RPM. This would seem safe at any reasonably low speeds. Is there any functionality trade off to setting a high max period?
Doesn’t that mean it wouldn’t be able to tell if the wheel is actually stopped?
If you look at the code the only reason it has that function is to not have a divide by 0 error. In the get period function, it uses that bool in order to not make it divide by 0.
Oh, yeah. Basically it will continue returning some higher speed that represents the last valid transition even though the wheel may have stopped some time earlier.
So we probably need to decide some happy medium rotational velocity that we want to control and set the period accordingly.
-al g
Note: the problem that we are dealing with is primarily due to the one pulse per revolution setup.
Agree that the stall feature is solving the zero divide problem but probably more importantly its dealing with the issue of period growing dramatically as rotational velocity approaches zero.
Take the following scenario: you decelerate very rapidly and your last transition happens at a time that is equivalent to 200 RPM. The wheel is stopped but the code continues to report 200 RPM. If the timeout (max period/min rate) is set for 10 RPM this will continue for 6 seconds.
Another interesting C++ fact that I never realized before (or once I knew but forgot):
For IEEE floats, division of a finite nonzero float by 0 is well-defined and results in +infinity (if the value was >zero) or -infinity (if the value was less than zero). The result of 0/0 is NaN. If you use integers, the behaviour is undefined.
The IEEE defined behavior is the same for LV, and I presume Java.
Greg McKaskle
It is pretty certain that is is going to be the same for C++/Java/LV as this behavior is typically determined by the FPU in the processor. I know that PPC conforms to the IEEE spec, and it properly handles x/0 for the three cases above.
I agree that PPC is IEEE 754 compliant, but some languages will have their own conventions, and since Java in interpreted, it would be pretty easy and efficient for them to have thrown an exception or taken some other action.
Greg McKaskle