mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-08-08 18:48:04 +00:00
8e243faa3a
## Problem `Toolchange temperature commands are unchanged when the wipe tower wait is off` (added in #15144) fails on both Linux runners and passes on Windows and macOS. It is the only failing test in the suite, and it has been failing on main since that PR merged. | Job | Result | | --- | --- | | Windows x64 / Unit Tests | pass | | Windows arm64 / Unit Tests | pass | | macOS arm64 / Unit Tests | pass | | Linux x86_64 / Unit Tests | **fail** | | Linux aarch64 / Unit Tests | **fail** | From the merge commit ([Linux x86_64](https://github.com/OrcaSlicer/OrcaSlicer/actions/runs/31072382258/job/92531704095), [Linux aarch64](https://github.com/OrcaSlicer/OrcaSlicer/actions/runs/31072382258/job/92531704075)), still reproducing on current main: ``` first difference at trace entry 29 main: M104 S240 T0 ; preheat T0 time: 31s lead 30.9s branch: M104 S240 T0 ; preheat T0 time: 30s lead 30.3s ``` ## Cause Each preheat entry records the same quantity twice: `lead` at one decimal, and `time:` inside the command text as that value rounded to a whole second. `split_lead` already compares `lead` with a 0.5s tolerance and explains why the estimate moves. `time:` sits in the exactly-compared command text, so it never got that tolerance — and being rounded, it flips on a drift far below 0.5s (30.4 and 30.6 render as `30s` and `31s`). Entry 29 is the only entry in the 163-entry golden whose lead rounds up; every other preheat sits at 30.0–30.4 and rounds down, which is why it is the only one that fails. The variation is per-toolchain, not run to run. Both Linux arches produce exactly `lead 30.3s`; Windows x64/arm64 and macOS arm64 all produce exactly `30.9s`. Repeated local runs are byte-identical. macOS arm64 passing while Linux aarch64 fails rules out the ISA — it is floating-point accumulation over a few thousand move durations under GCC vs Clang vs MSVC. The mechanism makes it discrete rather than gradual: the backtrace parks the preheat at the first exported line at least `preheat_time` before the tool change, so `lead` is `preheat_time` plus the leftover of whichever move that landed on. A sub-tenth difference selects the neighbouring move and `lead` steps by that move's whole duration. Entries 1–28 match exactly, including five earlier preheats whose leads fall inside the existing tolerance, so the toolpaths themselves are identical. I also reverted the two prime-tower commits that landed between the golden's capture point and now, rebuilt, and got a byte-identical trace — this is not behavioural drift. That also rules out regenerating the golden: no single capture satisfies all three toolchains, and recapturing on Linux would turn the three currently-green runners red. ## Fix Test-only. - `lead` keeps a tolerance, widened to 1.5s (measured drift 0.6s; a preheat actually leaving its backtrace position would move by tens of seconds). - `time:` is **not** compared across runs at all. Being a rounding of `lead`, it carries nothing the tolerance does not already cover, and comparing it across runs can only reproduce the flake. It is instead checked against its own entry's `lead` — a correct rounding keeps `|time - lead| <= 0.5`. That second point matters: simply tolerating `time:` numerically would have made the test blind to a real change, because drift and a wrong rounding both move it by 1. The self-consistency check keeps that coverage. I verified it by changing `(int) std::round(time_diffs[0])` to `(int) time_diffs[0]` in `GCodeProcessor::export_lines` — the test fails with `"time:" is not its entry's "lead" rounded to a whole second`, where a plain tolerance would have passed silently. Everything else is still compared exactly: all M104/M109 values, tool ids, block markers, ordering, entry count, and the annotation text including its trailing `s`. The other 138 entries remain byte-exact. No production code, no golden regeneration. The golden file and these helpers are used by this one test and nothing else, and the tolerance only widens, so Windows and macOS keep passing unchanged. A note is added to the golden's header so the next mismatch in those fields is not "fixed" by recapturing. ## How to verify Before, on Linux: ```bash git checkout main && ./build_linux.sh -t ctest --test-dir build/tests -R "Toolchange temperature commands are unchanged" --output-on-failure # fails at trace entry 29 ``` After: ```bash cmake --build build --config Release --target fff_print_tests ctest --test-dir build/tests --output-on-failure # 463/463 ```