mirror of
https://github.com/Klipper4FlashForge/firmware.git
synced 2026-10-22 21:32:16 -05:00
Oleksandr ShyshatskyiandClaude Opus 5
801cd4e897
Reverts the ff-orca-compat.cfg approach from 3fa8d33. The idea was to let FlashForge's stock slicer blocks run untouched by hooking homing onto SDCARD_PRINT_FILE and the print Z offset onto M109. It worked for the offset but not for the job as a whole. What killed it: START_PRINT is not mostly about the Z offset. T<n> already applies the ~3.2 mm gap on every grab, absolutely, so the offset command only adds three small job terms -- thermal (+0.045 mm at 220 C), hot bed (+0.08 at >=100 C), thin layer (-0.06 at <=0.10 mm). What START_PRINT really contributes is the sequence around them: G28, the bed mesh, M190 to wait for the bed, the re-home of Z once the bed is hot, the tool-presence gate and the nozzle clean. The stock block has no M190 at all -- the app waited for the bed before handing the file over -- so the implicit layer would have started printing on a cold bed. That is a first-layer adhesion failure with no error message, which is a worse outcome than the pasted macro call it was trying to save. Reproducing the rest of the sequence at hook points that do not line up with it would have meant reimplementing START_PRINT badly. So: one path, explicit. The Orca blocks call START_PRINT and END_PRINT, which do the work in the right order and in one readable place. Kept from the reverted work, all independent of which path is taken: test/test-macros.py and jinja2 in the build image, and a homed-axes guard on TOOLCHANGE_PARK in _FF_PRINT_END -- reached from CANCEL_PRINT after an error the axes may be unhomed, and raising there would abort the rest of the cleanup (heaters, fans, offset reset). Skipping the park is safe: the G28 wrapper docks a mounted tool before homing Z on the next job. Suite is 30 passed, 0 failed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GgNhSa1Qvwvxb2nQXT6b1Y
