It looks like we don't have to reset the whole ToolChange state machine when resolving an error with the middle button (Retry) - but jump straight into the feeding phase.
The reasons are multiple:
- If an error happens during the unload phase, it is handled separately in the UnloadFilament state machine
- If an error happens during the feeding phase, the unload has been already successfully completed.
And when restarted from the very beginning, the ToolChange does the last retract sequence from the UnloadFilament phase
-> that is not healthy, because the filament gets pushed away from the Pulley and causes another error.
Sets the UI module into a mode when the printer is in charge of processing the buttons (from all sources).
That means the MMU will detect its buttons but it will not react upon them.
This mode is important for error recovery when the printer needs to do some stuff before the MMU (like preheating the nozzle).
It looks we have some kind of leak when filament sensor state is not completely coherent with FINDA state.
This is yet to be discovered and fixed with some unit tests.
If the MMU receives a command LoadFilament with a slot number SL we reject
the command to avoid moving the selector (effectively cutting the piece of filament present in FINDA).
That includes the scenario when the selector is standing at the very same slot SL, because the filament could be held by the printer (i.e. loaded in the nozzle).
There is one special case though - same slot AND filament load state == InSelector (it MUST NOT be anywhere farther)
Using U_mm inside a compilation unit will force the compiler to generate
a runtime copy of the function, and we don't want that.
But there seems also to be an optimization problem with gcc <= 7.x where
even when declaring an inline function constexpr, if called enough
times, the compiler will choose _not_ to evaluate the function at
compile time and thus avoid our compile-time float->integer
conversions...
For this reason, split the body of the function in two parts: the actual
function that uses AxisUnits at runtime for calling motion.PlanMove, and
a wrapper that forces the conversion. By marking this function as
always_inline, the body is correctly evaluated at compile time at each
call site.
It turned out FINDA needs running timer to perform BlockingInit() correctly.
Therefore setup() was split into setup() (no IRQ) and setup2() (IRQ enabled).
Then, finally, the check for FINDA state became reliable upon start of the FW.
Originally, only FeedingToBondtech was reported to the printer.
With PR#173 we have this operation separated into a fast and a slow stage (for MK3S with the chimney).
It looks like the printer could benefit from knowing if the MMU is still pushing fast
or when it entered the slow stage (to prevent ramming hard the Bondtech gears)
Along with this new state being reported, we also introduce a new ErrorCode::FSENSOR_TOO_EARLY
which basically means that the fsensor triggered in the fast feeding stage.
- Check rates using the reported acceleration instead of deriving the
value from the slope.
- Simplify the tolerances when checking (use 10% for single-axis,
20% with multiple due to quantization)
- Check a broader range of values
The acceleration_rate should really by a premultiplication by 1<<24 so
that the division in Step() (while calculating the acc_step_rate) can be
computed again with a right shift.
This was incorrectly changed to F_CPU, which was close enough but would
cause the acceleration to be always slighly slower than expected.
Fix the ratio, but keep the multiplication in fixed-point to avoid a
float conversion.
Correctly compute both the number of steps and direction when
under/overflowing the current position by performing a relative move.
This makes a repeated PlanMove() _always_ perform the move correcly,
even when the upper-level code might require to handle the overflow
itself for measurement.
Add tests for this condition by exposing the internal CurBlockShift() to
the motion unit tests.
Do not assume any step can be merged while moving three axes at the same
time.
Use the worst case scenario involving indepedent parameters for each
axis.
This commit looks horribly complex, but the main idea is to have each of the logic::commands
report their terminal OK state in the same way. That allow for leveraging this very moment
to initiate the idle timeout.
Additionally, I wanted to hide the logic of idle mode detection, which resulted in moving the
top level logic from main.cpp into logic/idle_mode.cpp and a set of additional files to compile
in unit tests.
- circular buffer can return its count of elements (even though a better solution may be implemeted later)
- stub_motion can handle multiple planned moves
- improved load/unload filament tests
This PR brings the option to move the selector directly using
buttons of the MMU - obviously while the MMU is idle and no
filament is stuck in the selector.
Left/Right buttons move the selector Left/Right.
Middle button performs a LoadFilament (into the MMU) on the active slot.
With this PR a change of LoadFilament behavior is also introduced.
Now, LoadFilament spins the Pulley for infinite time while waiting
for either FINDA trigger and/or a button pressed.
While motion queuing is safe, code that relies on the current block
needs to run with the isr disabled.
Protect AbortPlannedMoves and CurPosition from isr' interference by
using a RAII guard.
D.R.racer
Yuri D'Elia
Alex Voinea