The little bump in the Klipper Load graph is when it was running a bed mesh.
CAN speed is 1M, twisted wire.
There’s no reason why it would suddenly repeatedly error out when only the CAN MCU changes, since the overall system load hasn’t changed, and the H723 has more than enough resources to easily handle this.
Does it work with the genuine BED_MESH_CALIBRATE ? (Note: Adaptive Mesh is now provided by Klipper)
BTW:
The printer.cfg appears to unstructured. Additional macros just put at random points.
What I mean:
It starts with [stepper_extruder], then [tmc2209_extruder], the [stepper_x], then various macros (all of need?), then some other setup essentials, then [stepper_y], [stepper_z], then some other essentials, then [tmc2209 stepper_x] (now?), [tmc2209 stepper_y] and [tmx2208 stepper_z] (are you sure about the 2208?, maybe it’s the culprit).
There are no random macros, they’re in seperate files, all which are loaded via [include] at the beginning of the config. And yes, all needed.
And yes, the 2208 is correct.
It even happens when simply homing, no bed mesh calibration started at the time.
None of your points would explain why it fails ONLY in canbridge mode on the SKR3, and never in canbridge mode with the RP2040 or with an USB CAN adapter. The config is exactly the same.
The UI does show it as dirty, it just doesn’t display it exactly the same way. You’ve added three files that are not part of Klipper and could be doing almost anything. While it’s not necessarily related to your problem it’s best to test with unmodified Klipper.
The three files are part of the autotune script (currently not being called by Klipper at all) and gcode_shell_command, which is very common. Again, these are always active with both the SKR in canbridge mode and another method of connecting CAN, so if they were interfering, they’d do that in both cases.
I switched to the USB CAN board again now (since I kinda need a working printer), and it instantly works fine again, two full mesh runs with not a single hickup.
A debian bug has crept in some distros that should have been fixed in bookworm 11/12/23, it caused problems with /dev/serial creations may be connected just trying out on oct pro h723 now.
This is an error due to timing mismatches between host and board.
Even the slightest change in timing behavior can provoke this error. Unofficial modules MAY lead to such and are definitively a reason not to look further into such reports as it may be a total waste of time when finally the error is caused by such modifications.
got email late on phone got you mixed up with a discourse convo, but that bug did tke out my EBB42 after an update, my octopus pro h723 still showing as can adapter, but EBB42 no longer found.
