Commit b60804bb changed the trapq head sentinel to store
print_time=-1. However, it failed to update trapq_add_move() that
relied on that value to detect the head sentinel. As a result,
numerical stability issues could lead to stepcompress errors.
Fix by changing trapq_add_move() to detect the head sentinel even with
a negative print_time.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Numerically optimized versions of *EI shapers have been tuned
for specific ranges of damping ratios and will show poor stability
outside of these designated ranges.
Signed-off-by: Dmitry Butyugin <dmbutyugin@google.com>
The code currently adds an additional 100ms to BUFFER_TIME_HIGH in
_check_pause() to reduce the number of calls to _check_pause().
However, LOOKAHEAD_FLUSH_TIME should already provide sufficient
batching so adding more is not necessary. This change should
hopefully make configuring BUFFER_TIME_HIGH a little more transparent.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Due to differences in mcu clock vs system clock it's possible to
repeatedly underestimate a system delay needed to bring about a
sufficient mcu time - which just wastes cpu cycles retrying a pause.
It's okay to sleep a slightly longer time to avoid the issue.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Previously the code would always keep at least 2 items on the
lookahead queue after a "lazy" flush. In most cases it's okay to
leave only a single item. Update the code to better handle flushing
of items that are fully ready.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Replace "delayed" storage with a full pass through the queue. This
simplifies the lookahead processing logic.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Avoid using "smoothed" and "accel_to_decel" for variables associated
with minimum_cruise_ratio. Instead introduce the prefix "mcr" for use
with these variables.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Commit 7ea5f5d2 changed how the lookahead queue is flushed.
Previously, the main flush timer would always run while the toolhead
was considered in an active state (print_time). After that commit,
the flush timer could sleep if there were no steps generated (no call
to note_mcu_movequeue_activity() ). This could lead to a situation
where a G4 command (or series of commands) could cause the toolhead to
be considered in an active state while the flush timer was disabled.
The result was that a future command may not be properly flushed (the
toolhead would fail to transition to a "Priming" state).
Fix by ensuring that all dwell() requests fully flush the lookahead
queue.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Commit a89694ac changed the code to run itersolve_generate_steps()
from multiple threads simultaneously. However,
trapq_check_sentinels() can modify the shared trapq object. So,
calling it from multiple threads could introduce a race condition.
Move the call to trapq_check_sentinels() to steppersyncmgr_gen_steps()
to avoid the issue.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Implement step generation from 'struct syncemitter' instead of in the
stepcompress code. This simplifies the stepcompress code and
simplifies the overall interface.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Move msg_queue allocation from stepcompress to syncemitter. With this
change the pwm_tool module does not need to allocate a stepcompress
object.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Create a new 'struct syncemitter' for each object that can generate
messages for a 'struct steppersync' and store in a regular linked
list.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add a new C based mechanism for tracking all the 'struct steppersync'
instances. This simplifies memory management.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Don't rely on an exact floating point number match to detect when a
forced lookahead flush is needed.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Use the next_batch_time even if it is slightly past or before the
ideal flushing window. This should improve run to run reproducibility
of flush timing.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that the host code does not flush far into the future, it is no
longer necessary to flush in waves. Integrate _advance_flush_time()
into _flush_motion_queues().
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
If a flush_all_steps() request is for a time far in the future, then
wait for that time to become close prior to flushing steps. This
avoids committing to a step schedule that is far in the future.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Don't tie the step generation logic to the toolhead lookahead logic.
Instead, use regular timers to generate steps with a goal of staying
500-750ms ahead of the micro-controllers.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>