Quote:
Originally Posted by Ether
What you suggest will likely work for this non-critical application whose running time is less than three minutes.
However, for the benefit of those reading this thread who are just learning about realtime control, and who may go on to program other realtime applications, the following caveat should be pointed out:
The 2010 FRC LabVIEW framework is most definitely NOT hard-real-time. Using code running in cRIO to re-set the FPGA counter is not a robust solution if high accuracy is required and you do not want to introduce errors that may accumulate over time.
At the very least, the reading and re-setting of the FPGA counter should probably be protected by a critical section to minimize the occurrence of accumulated errors.
~
|
I'm not sure what you're saying here.
As far as I know, there is no cRIO code resetting the FPGA counter. My point was as follows (I didn't state it very clearly):
As long as:
1) the encoders are decoded by an interrupt handler in the FPGA
and
2) the cRIO samples the FPGA counter fast enough such that it cannot do a complete overflow cycle (e.g. the encoder cannot rotate more than 65536 counts (if 16-bit counter is used) in one cRIO sample).
and
3) The WPI code uses the difference between the current FPGA count and the previous FPGA count (instead of the absolute FPGA).
THEN
FPGA overflow does not matter, since the two's compliment math in the subtraction in step 3 above will work even in an overflow situation. You can run the cRIO for three years (not 3 minutes) and you will not see an issue from the FPGA counter. You will, however, eventually overflow the double-precision distance calculation from the WPI code, but that has nothing to do with the FPGA overflowing.