Scott Lahteine

Homing depends on being able to distinguish that a move is occurring in a particular axis, not just with a particular stepper. For Marlin standard Core kinematics motion we set...

We could possibly set the move and direction flags for `CORE1` and `CORE2` as soon as the new planner block is fetched, assuming that FT Motion immediately starts processing. However,...

> …we could probably set the corresponding fields in `last_direction_bits` when the block is loaded and before his processing begins… As long as there's no "pre-fetching" going on that should...

> …the directions are valid until the end of block processing… That being the case, do we really need to include DIR information in the FT Motion command buffer, or...

I've done a bit more cleanup on this, adding a shared method `set_axis_moved_for_current_block` used by both standard motion (`block_phase_isr`) and FT motion (`ftMotion_blockQueueUpdate`) when fetching a new block, so any...

> is `endstops.update()` mandatory outside the homing function? Endstop states are tracked continually, but only interrupt motion when they are "enabled." They may be enabled during printing for a feature...

> `ENDSTOPS_ALWAYS_ON_DEFAULT` is probably the most common case I see when helping users. Only 4 of our example configs have this option enabled. It's only recommended for users who really...

> I made some tests with a flag set in `G28` on entry and unset on exit. `hx`, `hy` and `hz` are set as before in `ftMotion_blockQueueUpdate` only if the...

> `axis_did_move` needs to be updated every time we pop-up a new command from the buffer as we don't know which block it belongs to. Previously we updated `axis_did_move` to...

> Regarding `if (current_block->is_pos_sync()) _set_position(current_block->position)`, it's always `true` in the `while` loop context for a standard printer but not always for a laser machine. The position sync flag (`flag.sync_position`) returned...