Conversation
HOME_FINAL_MOVE_START is meant to wait HOME_DELAY after the joint has stopped before it plans the move to HOME, like every other *_START state. The 'break' after pause_timer++ was missing, so the timer was incremented and immediately cleared, and the final move was planned in the first servo period after the joint stopped. Add the 'break'. Check the negative HOME_SEQUENCE sync before the delay, not after it: otherwise a joint that is already waiting can time out and latch sync_now while its partner has just arrived and is still in its own delay, and the synchronized final moves would start up to HOME_DELAY apart instead of within one servo period as now.
With the delay now honored in HOME_FINAL_MOVE_START, a joint homed in place (HOME_SEARCH_VEL = HOME_LATCH_VEL = 0, or HOME_ABSOLUTE_ENCODER) stayed in homing for HOME_DELAY although it never moved, so a home request for the next joint issued right after it was dropped and tests that home joints back to back (maxkins, matrixkins, kins-switch, single-step, hard-limits, abort/*, interp/g28.2/*, ...) failed. Wait only when the joint made a search or latch move: that is what the delay lets settle. Homing in place finishes in the same servo cycle as before.
|
Reproduction in sim, and a correction plus a regression found while doing it. Correction to the description: Setup (master f7ccc4f vs. the same patch on master, Debian trixie, RIP uspace; the 2.9 hunk is identical): trivkins, one joint,
Regression: with the patch as it is, 15 tests of A follow-up commit applies the delay only to a joint that made a search or latch move ( |
HOME_FINAL_MOVE_START is meant to wait HOME_DELAY after the joint has stopped before planning the final move, and the final moves of a negative HOME_SEQUENCE pair must still start together. Check both in sim by polling joint.N.home-state. Fails on current master (final move starts 1-2 servo periods after the stop); passes with "homing: wait HOME_DELAY before the final move". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QARseQ7Wp54ytTTisVrtvm
|
Thanks for the careful measurement, the home-state table is convincing. Two things to fix though. The issue body is wrong about Tested on master, targeted at 2.9. The PR bases on 2.9, but all numbers and the full test run come from master f7ccc4f, with 2.9 itself never built. For a released stable branch that is backwards: the bar there is regressions that hurt users, verified on that branch. And this patch does hurt users: your own run shows 15 previously-passing tests failing, because a joint that never moves ( Some history for context: the break was dropped in the 2022 state-machine rework ( My suggestion: retarget at master with the v2 gating folded in, and treat "should the final move wait |
|
Thanks, Luca, for the review and the history. You're right on both points.
I'm closing this. We found it by reading the code, not because a machine misbehaved, so we have nothing from the field that would justify new behavior in master either. The diagram that still says "after HOME_DELAY" is corrected in #4628 (docs only). If we ever measure a drive that really needs a pause before the final move, we'll come back to master with the data, as a design proposal. |
Since the 2022 homing state-machine rework the HOME_FINAL_MOVE_START state plans the final move as soon as the joint has stopped (and, for a negative HOME_SEQUENCE, the other joints of the sequence are ready); there is no HOME_DELAY pause before it (src/emc/motion/homing.c, the timer branch of this state has no break). The diagram still showed 'after HOME_DELAY' on that edge. Describe the actual behavior; no code change. See #4621.
2 participants
Closed, not merged — see the discussion below. Description corrected after review.
In
base_1joint_state_machine()every*_STARTstate waitsHOME_DELAYafter the joint has stopped: the timer branch ends withbreak. InHOME_FINAL_MOVE_STARTthatbreakis missing (since the 2022 state-machine rework), sopause_timeris incremented, immediately cleared, and the final move toHOMEis planned without the pause. The developer state diagram (docs/src/code/homing.dot) still shows "after HOME_DELAY" on that edge.HOME_DELAYis not an INI setting. It is the compile-time constant#define HOME_DELAY 0.100insrc/emc/motion/homing.c(line 54 on 2.9, 55 on master), i.e. 0.1 s.How to see it: a sim config with a home switch and a non-zero
HOME_OFFSET, e.g. trivkins, one joint,SERVO_PERIOD = 1000000,sim_home_switchat -2,HOME_SEARCH_VEL = -10,HOME_LATCH_VEL = -1,HOME_OFFSET = -1,HOME = 0,HOME_FINAL_VEL = 5. Recordjoint.0.home-stateandjoint.0.motor-pos-cmdevery servo period withsampler(halsampler -t) while homing. On master f7ccc4f the joint spends 2 periods inHOME_FINAL_MOVE_START(state 20) beforeHOME_FINAL_MOVE_WAIT(21); with thebreakadded it spends 102 periods (0.1 s =HOME_DELAY).Adding the
breakalone breaks 15 tests that home joints back to back withHOME_ABSOLUTE_ENCODERor zero search/latch velocities: such a joint now waits 0.1 s and the next home request is dropped. Gating the delay on joints that actually moved fixes that, but that is new behavior, not a stable-branch fix, and we have no field measurement of a drive that needs the pause. The diagram is corrected separately in #4628.