Is your feature request related to a problem? Please describe.
Banding on bidirectional raster engraves is a common issue with several possible causes. On my machine it shows up as a fixed, constant-across-speeds misalignment between left-to-right and right-to-left passes - other research/discussion suggests some machines see a speed-dependent version instead (the timing-delay case LightBurn's speed table addresses). The docs currently suggest disabling bidirectional scanning to work around banding in general, but that costs roughly half your engraving speed and that toggle doesn't actually exist anymore anyway (it was removed when the raster producers were unified, the docs just never caught up).
Describe the solution you'd like
Add a bidir_scan_x_offset_mm parameter on the Rasterizer producer (per engrave step, not a single machine-wide setting, since different jobs may want different corrections and this may need to vary by speed in the future) plus a BidirScanOffsetTransformer that shifts each right-to-left pass along X by that offset during gcode generation. Also extend the existing Material Test Grid feature with a new "Speed vs Offset" mode so the value can be calibrated empirically by eye, rather than guessed at.
I have a working proof-of-concept branch, fully tested (unit tests for the transformer, the producer wiring, and the new grid mode): https://github.com/vyvcodd/rayforge/tree/feature/bidir-scan-offset-per-step
Describe alternatives you've considered
- A single machine-wide offset (Advanced Preferences) - simpler, but can't vary per job, and can't later account for offset varying by speed.
- A full speed-to-offset table, like LightBurn's - would also handle the speed-dependent case, but is significantly more complex to build and use, and can't be manually tweaked per job. My own issue is constant across speeds, so this felt like solving a problem I don't have (YAGNI) should be straightforward to add later if a per-speed value turns out to be needed.
Additional context
A couple of open questions from building the calibration grid mode that I'd like input on before turning this into a PR:
The grid mode change also doubles the auto-calculated overscan distance for test blocks (helps isolate the offset from backlash settling) and disables the Optimize transformer (its nearest-neighbor travel reordering has no concept of cell boundaries and was interleaving lines from different cells). Both changes apply to all material test grid modes, not just the new one - arguably useful everywhere, but maybe should be an option instead?
Is your feature request related to a problem? Please describe.
Banding on bidirectional raster engraves is a common issue with several possible causes. On my machine it shows up as a fixed, constant-across-speeds misalignment between left-to-right and right-to-left passes - other research/discussion suggests some machines see a speed-dependent version instead (the timing-delay case LightBurn's speed table addresses). The docs currently suggest disabling bidirectional scanning to work around banding in general, but that costs roughly half your engraving speed and that toggle doesn't actually exist anymore anyway (it was removed when the raster producers were unified, the docs just never caught up).
Describe the solution you'd like
Add a
bidir_scan_x_offset_mmparameter on the Rasterizer producer (per engrave step, not a single machine-wide setting, since different jobs may want different corrections and this may need to vary by speed in the future) plus aBidirScanOffsetTransformerthat shifts each right-to-left pass along X by that offset during gcode generation. Also extend the existing Material Test Grid feature with a new "Speed vs Offset" mode so the value can be calibrated empirically by eye, rather than guessed at.I have a working proof-of-concept branch, fully tested (unit tests for the transformer, the producer wiring, and the new grid mode): https://github.com/vyvcodd/rayforge/tree/feature/bidir-scan-offset-per-step
Describe alternatives you've considered
Additional context
A couple of open questions from building the calibration grid mode that I'd like input on before turning this into a PR:
The grid mode change also doubles the auto-calculated overscan distance for test blocks (helps isolate the offset from backlash settling) and disables the Optimize transformer (its nearest-neighbor travel reordering has no concept of cell boundaries and was interleaving lines from different cells). Both changes apply to all material test grid modes, not just the new one - arguably useful everywhere, but maybe should be an option instead?