Unexpected results from Encoder::GetRate()

[jhersh]

Originally Posted by vamfun

.
Well, Ill have to work on you a little more. This flag would make the register a complete representation of the A/B state information which doesn't seem like a bad thing. I don't think a fast read would be practical solution.

My general feeling about indicators that only stick around for one tick of something is that they are basically useless in a register interface. I designed the interfaces to isolate the timing of the measurement from the code that needs it, meaning the code can stop by any time it wants and ask for a value. What you are proposing would only be set for one tick of the encoder, and the information is already available as the change in value of dir. If you look for a change in value of dir, you can get that information any time you read. If you are looking at your proposed same edge flag, then you have to read before the next edge or you've lost the information. Hence my statement that you would have to read fast enough to catch every edge in order to make use of such a bit.

Perhaps I could make the same edge event set the stalled bit immediately, since a same edge represents a stop (except in the ridiculous noise case).

Originally Posted by vamfun

I worry about a position servo case which drives to a reference and then holds zero rate. You may not be able to turn off a motor if there isn't sufficient braking torque to hold the controlled object.. ie a heavy manipulator arm.

As Alan stated, use a position controller, which doesn't use the rate output, it uses the position output.

Originally Posted by vamfun

Can you pipe the DIR flag into the pipeline so there would be 0's and 1's in the pipe line ? If so, couldn't you construct a recursive pipeline sum by summing the 1's in the pipeline and then computing a signed_sum = 2*(sum of 1's) - max_count. Then in GetRate() compute rate = (signed_sum )/period rather than 1/(period/max count). The summation would take a little extra time... not sure what the FPGA could do to optimize this.

What is the benefit to this? Just cancelling out one set of rates for each dir change?

-Joe