SS out of bounds error after restart

[river parrot]

Been printing with SS and all is great. Since the latest release I’m getting the weird issue that, when restarting a failed print via the ‘reprint printer icon’ an out of bounds move error is triggered.

This never happens when doing a clean start or pushing the broom icon before restarting.

SS is set to relative mode as per the RR vcore profile.

From advice given in de slicer channel an assumption was that there might be a G90 or G91 in the start print Macro which I confirmed exist (twice) in the ratos ‘START PRINT’ macro.

Any help to figure out what is going on here would be awesome so Ik now if it’s human error or a bug report for SS.

[stuck kraken]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[slow zealot]

@river parrot look in printer.cfg

[gcode_macro RatOS]
variable_relative_extrusion: False

is that false or true?

[river parrot]

It’s set to true

[slow zealot]

Hmmm. We have different issues then, yours must be specific to the reprint function

Actually, let me hit that button

I did not have that issue

relative e enabled in config and slicer - I was able to hit reprint in mainsil without issue

[proper fox]

Been printing with SS and all is great. Since the latest release I’m getting the weird issue that, when restarting a failed print via the ‘reprint printer icon’ an out of bounds move error is triggered.
You're most likely getting tricked by klipper compensation algorithms.

From advice given in de slicer channel an assumption was that there might be a G90 or G91 in the start print Macro which I confirmed exist (twice) in the ratos ‘START PRINT’ macro.
No. All RatOS macro's restore gcode state, they will not change whatever the state was before you ran it.

Have you added anything like z_thermal_adjust, skew (without using the built-in ratos skew profile variable), axis_twist compensation or any other compensation functionality?