Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ntcore] Special-case default timestamps #5003

Merged
merged 2 commits into from
Jan 25, 2023

Conversation

PeterJohnson
Copy link
Member

@PeterJohnson PeterJohnson commented Jan 24, 2023

Previously, a setDefault() on the server could override a client doing a real set() if the time offset between client and server was negative, resulting in a negative timestamp from the client. This is a not uncommon situation with robot code, as the robot code always starts at time 0, so any clients that set values earlier (in real time) would have negative timestamps.

Also improve special casing of 0 in the transmit side to make sure a normal timestamp will never get sent as 0.

Fixes #5002.

TODO:

  • Add tests

@PeterJohnson PeterJohnson requested a review from a team as a code owner January 24, 2023 23:59
Previously, a setDefault() on the server could override a client doing a
real set() if the time offset between client and server was negative,
resulting in a negative timestamp from the client.  This is a not
uncommon situation with robot code, as the robot code always starts at
time 0, so any clients that set values earlier (in real time) would have
negative timestamps.

Also improve special casing of 0 in the transmit side to make sure a
normal timestamp will never get sent as 0.
@PeterJohnson PeterJohnson merged commit 8785bba into wpilibsuite:main Jan 25, 2023
@PeterJohnson PeterJohnson deleted the nt-fix-negative-time branch January 25, 2023 19:36
Starlight220 pushed a commit to Starlight220/allwpilib that referenced this pull request Mar 2, 2023
Previously, a setDefault() on the server could override a client doing a
real set() if the time offset between client and server was negative,
resulting in a negative timestamp from the client.  This is a not
uncommon situation with robot code, as the robot code always starts at
time 0, so any clients that set values earlier (in real time) would have
negative timestamps.

Also improve special casing of 0 in the transmit side to make sure a
normal timestamp will never get sent as 0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

NetworkTables Publishers do not re-publish values when reconnecting to the robot NetworkTables server
1 participant