You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been running some tests on my TReX rig, to see what happens when the encoder count overflows from both MAX_LONG to MIN_LONG and vica versa (the encoder lib allows a value to be written, so I don't have to wait forever to set up the overflow). I don't see a problem. If we subtract the previous reading from the new reading, the difference will always be correct across the boundary. Am I missing something here?
On 13 April 2017 at 22:08, markwomack ***@***.***> wrote:
I have been running some tests on my TReX rig, to see what happens when
the encoder count overflows from both MAX_LONG to MIN_LONG and vica versa
(the encoder lib allows a value to be written, so I don't have to wait
forever to set up the overflow). I don't see a problem. If we subtract the
previous reading from the new reading, the difference will always be
correct across the boundary. Am I missing something here?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#48 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAX2f2OwHxe4iIxijtx68V2wyM6hlLdeks5rvv9XgaJpZM4M64SD>
.
In doReadEncoders() is probably the ideal place to handle it.
The text was updated successfully, but these errors were encountered: