Diagnosing "Move out of range" errors

General Discussion
1

Basic Information:

Printer Model: Tridex
MCU / Printerboard: BTT Octopus (possibly others)
Host / SBC: raspberry pi (possibly others)
klippy.log

Describe your issue:

I write and maintain some macros for Klipper based IDEX printers. I recently re-wrote the macros in order to add more functionality, but a few users are having an issue with “move out of range” errors that I just cannot figure out.

The error occurs when they have the tool change method set to “swap” mode. Similar to the Ratrig Vcore IDEX tool shift. However the error only occurs mid print. So after a few layers of everything working fine, on one of the tool changes they get the “move out of range” error with coordinates well within their build area. When they use another tool change method, “classic” or “ooze_prev” they do not get the error.

I have tested the gcode they are using on my printer and I get no errors.

In the attached zip file are 3 log files, the gn-klippy.log and mz-klippy.log contain the errors. My klippy.log is there for comparison.

I am very careful in the macros to limit relative mode to a couple G commands then switch back to absolute mode.

If there is a way to get more detailed information in the klippy.log I would like to know. I have hacked in the macros a bunch of console messaging that lets me pin down where the error is occurring as far as processed gcode goes. But I don’t know if the information I have is enough to solve the issue, and I don’t know how to proceed from here.

Any assistance would be greatly appreciated.

klipper_logs.zip (777.4 KB)

2

So I have done some more digging and found that the errors only occur on machines that have a high system load according to the log files. People that do not have a high load seem to be able to use the “swap” tool change without issue.

So it looks like Klipper is processing a G0 move command before finishing the previous called macro. Which sets the positioning to relative, then moves in the Z by a specified amount, then resets positioning to absolute. Then the next movement command is what gives the move out of range error. I have tried adding M400 commands before and after movement sections to make sure it is processing the commands properly. But it does not seem to help.

Still looking for ideas on why this would be happening at random points in a print for people.