Files
menzel f9ff89dc73
CI for csaxs_bec / test (push) Successful in 1m43s
fix(cont_grid): apply the premove along the direction of travel
The premove exists so the fast axis is already at speed when it reaches
the first point and still moving past the last one. It was applied with
a fixed sign:

    self.fast_start -= premove_distance
    self.fast_end   += premove_distance

which only lengthens an ascending line. On a descending one both ends
move inward instead: the stage starts past the first point and stops
before the last, with no run-up at either end, while frames_per_trigger
-- computed earlier from the original range -- still expects the full
travel, so the tail of the burst fires into a stage that has already
arrived. When the premove exceeds half the range the two ends cross over
and the line runs backwards; the test fixture's premove is 10.0 against
a range of 2.0, so that is the case it covers.

Latent rather than live: fast_axis_always_in_pos_dir defaults to True
and normalises a descending request to an ascending line before any of
this runs, so the wrong sign is only reachable when a caller passes the
flag as False. The flag is a documented scan argument, so the path is
real -- but no scan taken at the default has ever gone through it.

Also pins the normalisation itself. It is worth a test of its own
because it means a scan file records fast_start > fast_end while the
stage ran the other way, which is a trap when reading data back: the
first point of a line is at the numerically *lower* end regardless of
what the request said.
2026-08-25 21:38:50 +02:00
..
2026-06-24 12:55:32 +02:00