Single MCU vs 3xMCU step rates on a Delta

I’m currently using a Duet Wifi with Klipper on my delta and recently went through some calculations regarding step rates as I wanted to see if I can bump up microstepping from x16 to something higher (and I’m also phantasizing about a gear reduction system on annew project.

I arrived at these calculations:

  • Duet WiFi ~1650K steps/s with 3 steppers active
  • 160steps/mm for 0.9deg motors and 20T pulley
  • 3 steppers concurrently active
  • x16 microstepping

(1650*1000)/160/16/3 = ~215mm/s on pure Z moves

While there barely (if ever) all 3 steppers need to move at these step rates simultaneously ot could get ugly with further microstepping.

Looking at the benchmarks a single RP2040 (Pi Pico) could deliver up to around 2400K steps/s - if I put an RP2040 in for each tower would that result in ~7200K steps/s with all 3 motors active?

Are there any drawbacks regarding synchronization and/or USB saturation on an rPi3B or rPi4?

Using the formula above this would allow me to seriously bump up microstepping or use a bigger gear ratio:
A - same conditions as above)
(2400*1000)/160/16/1 = ~937mm/s (for pure Z-moves)

or B1 - x32 microstepping)
(2400*1000)/160/32 = ~468mm/s

or B2 - x32 microstepping)
(2400*1000)/160/64 = ~234mm/s

or C1 - 1.8 deg motor with 16 microstepping and 4:1 reduction for reduced error compared to 0.9 steppers by 50%)
(2400*1000)/(80×4)/16 = 468mm/s

or C2 - 1.8 deg motors with 128 microstepping and no reduction)
(2400*1000)/80/128 = 234mm/s

Is my thinking wrong?

//Edit: corrected some numbers

I’m not aware of any issues with running a micro-controller per delta tower, but I’m also not aware of anyone who has tested that. Note that you would not be able to use an automatic z-probe in that configuration due to limitations on multi-mcu-homing ( Multiple Micro-controller Homing and Probing - Klipper documentation ).

Note that increasing microsteps above 16 does not improve positional accuracy. (It may help with reducing noise.) So, the additional complexity of deploying additional micro-controllers would only seem to make sense if you had a specific requirement for a particular speed with a particular microstep setting.

-Kevin

Thank you for your reply! Not being able to use a z-probe (Smart Effector in my case) is indeed something I overlooked. This is pretty significant imho, especially on a delta.

Whilst microstepping doesn’t increase resolution, a gear ratio might (which would’ve been my primary goal in the experiment). If that’s something that can be actually beneficial in real life is something that I wanted to find out.

In theory it could cut down possible positioning errors of > 0.1mm in some areas of the bed down to half which could potentially eliminate concerns about those kinematics and bring it on par with cartesian kinematics where we’d usually be seeing 5/100th mm +/-5% positioning accuracy (given 0.9 deg motors) across the bed, ideally without compromising on top speed.

Bonus question:
The limitation of multi-mcu homing / automatic z-probe would also kick in when I’d have a custom “smart effector” design with it’s own MCU, correct? Because that’s another experiment I had in my head to simplify wiring for a quick change effector. So I’d need to run the Z-Probe connection back to the single “master” mcu controlling the towers then?

No - multi-mcu-homing works fine in that case. The current limitation is that you can’t have multiple Z MCUs and a separate endstop/probe MCU. If all the Z steppers are on one MCU then you can have a separate endstop/probe MCU.

-Kevin

1 Like