The initial clock measurement wasn't properly implementing a small
delay between clock queries. Fix the pause() call so there is a small
delay between queries.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Introduce a main send_with_response() helper function and use it
during identify and the setup of clocksync.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
In some rare circumstances it was possible for the host software to
become so busy that it does not transmit a get_clock request for
several seconds. (In particular, this could occur with some complex
calls to coordinate_descent.) If that happened, it was possible for
the code to incorrectly report a "Timeout with MCU" error. Rework the
is_active() check to prevent that.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Change the get_status command to get_clock. Don't report the shutdown
status in the new get_clock command.
The primary purpose of this change is to force the host code to report
a firmware version mismatch with older firmwares as recent changes
(namely the ordering of message block acks) have subtle
incompatibilities if different host/mcu code is used.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
If the clock querying messages occur at a similar frequency to other
events on the micro-controller or host, then it's possible for the
load created by those other events to skew the clock synchronization.
In particular, the 500ms lcd screen update could resonate with the 1
second clock query. Use an unusual clock querying frequency to avoid
this issue.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add a lookup_command() method to the SerialReader class that provides
a wrapper that stores the serial and commandqueue references. This
makes it easier to run the send() method.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The multi-mcu clock syncing code relies on the ability to periodically
update the mcu clock adjustments. If a series of very long moves are
submitted then it is possible the adjustments could become unstable.
For example, if an adjustment is made to reduce a clock error over the
next couple of seconds, but it is applied to a longer period because
the next move lasts many seconds, then this would result in a bigger
adjustment for the following move, which would result in an even
bigger error when that move lasts many seconds. This can repeat until
the system destabilizes.
Check for cases where the print_time is far in the future of the
current estimated print time and average over a longer period in that
case. That should reduce the possibility of the adjustment code
becoming unstable.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Average clock sync times over approximately 30 seconds instead of 120
seconds so that the clock prediction responds to changes faster.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Don't discard samples that are less than 500us from the prediction
regardless of the prediction variance. Also, don't use the prediction
variance in the external time estimate.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Implement a "moving" linear regression between the reported mcu clock
and the sent_time of the get_status message that generated that
report. Use this linear regression to make predictions on the
relationship between the system time and the mcu clock.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Revert commit f37fc775. It is not valid to pass a conservative
frequency to serialqueue.set_clock_est() as that function may not be
called for extended periods - a too low frequency would eventually
lead to "Timer too close" mcu errors.
Instead, increase the 1ms time offset to 5ms to avoid corner cases
that could lead to a message arriving too soon.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
This prevents divide by zero errors during stats output if the stats
are generated before a connection completes.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Accuracy is not as important as ensuring a message is never sent
before it can be received in the serialqueue code. So, use the
smallest frequency ever seen and add the minimum rtt time when setting
set_clock_est().
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Instead of tracking the minimum frequency ever observed, attempt to
track the actual frequency of the micro-controller (relative to the
host clock). This improves the stability of the secondary mcu clocks
when multiple mcus are configured.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add initial support for controlling multiple independent
micro-controllers from a single Klippy host instance. Add basic
support for synchronizing the clocks of the additional mcus to the
main mcu's clock.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Everywhere the data in get_last_clock() is used can be done just as
easily with estimated_print_time().
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Kevin O'Connor