It gets the last received update from the Talon, and returns quickly. A common strategy is to servo until getClosedLoopErr() returns an acceptably small value for say 5 loops in a row.
So increment a counter if the closed loop error is small, and clear it when its large.
If counter > 5, then return true in your command’s isfinished implem.
getClosedLoopErr, does not take a timeout. It gives you the latest value received.
By default that signal group updates every 160ms. You can speed up the update rate, see here.
10ms should be good. Just keep an eye on your CAN bus Util (DS lightening tab) and keep it under 90%.
Because it is mechanism specific. You will also likely need to debounce simply because of momentum and the requirements of your mechanism. Typically you will want the mechanism/game-piece to “settle”, before moving on. But you also want to tweak this to be as fast as you can get away with (auton time, etc.).
A typically well-tuned system will overshoot slightly, and you typically want the overshoot corrected before you move on. So don’t stop the command just because one sensor sample is “close enough”.
configAllowableClosedloopError allows the MC to stop driving the motor if the target is “close enough”.
But just because the motor is not applying voltage does not mean the mechanism is settled.
Some general references for posterity…
Java Pos closed loop example
Java Motion Magic example