Hi, I built a concept printer based on a Micron. This printer does not have a central controller board. Every stepper has its own MCU attached (including a TLE5012B - but this is a different story). These are all connected to the Pi by a CAN bus. So far, so good! But now, I realized that controlling four steppers on the Z axis is not supported in a multi MCU setup…
My question is, would it be possible to do this? And what needs to be adapted to support this in Klipper?
Thanks!
In the meantime, I studied the code and could not see any reasons why multi MCU homing should not work. So, I remove the constraint and was able to home, do QGL, do my auto z calibration and test the first prints 
But, I did not dive deeper into the syncing - maybe I missed something there?
What I have discovered so far, I need to probe very slow to get repeating results, the CPU consumption is very high of the main Klipper process while probing. I got homing timeouts with a Raspberry 3A+ and need to stop KlipperScreen.
And the last thing, I had to switch the CAN bus to 1Mbps to be able to complete a resonance test. With the A, B steppers and the tool head on different CAN MCUs, I get a bus usage of about 60-80% while the test is running. So, 500kbps are definitely not enough. Or does this sound weird?
It is possible to remove the constraint and the code should run to completion. However, this introduces the possibility of subtle position errors. Each time that one does a PROBE operation each Z motor may move one or more extra steps and the code will not correct for this overshoot. That is, if one were to align the Z steppers using Z_TILT_ADJUST and/or QUAD_GANTRY_LEVEL, then each future PROBE operation may subtly misalign the Z carriages.
So, it’s fine to disable the error checking for testing, but be aware that there are known positional errors that may result.
If reading accelerometer data over CANbus, then yes, I’d highly recommend using 1Mbps. The accelerometer produces a lot of data.
-Kevin
Ok, so the reason is in the synchronization that the overshoot is not corrected. Is there any chance that this could be added? Or would the architecture make that difficult?
I have now published the serial video and a few photos in the Voron Discord. I think that I have aroused the interest of some for such a decentralized setup…
Kevin, are you able to help quantify the position error here, as steps, or microsteps, and how to estimate the potential? For systems with heavy Z reduction, the error may not be unacceptable as-is. Curious…
If something is merged into mainline, the expectation is it works without restrictions. People will use the feature without understanding the limitations, and that will lead to support requests and upset users who invested in hardware that might not work well. As a helper on Discord, I’m not a fan of adding a feature like this if it has known problems.
I’m not sure what you mean by that. Although I understand your concerns. There is a limitation and that is what is being tested for. I don’t want that check to be removed just like that either. I would like to see the restriction removed - if that is possible. At least as good as it works with multi MCU homing.