Sync Multi stepper CNC setup


Since I just found out how painfully laud my TMC2660 drivers are, I was thinking of a way to sync the moves of multiple steppers, running SimpleFoc on a dedicated MCU but sharing the Gcode. Another solution for the noise would be to upgrade to TMC5160 and hope for the best, knowing the best best would be closed loop.

As I understand it, SimpleFOC (for steppers) does not work with dir/step, like a typical main board?
So how can one sync the movement ?

Im thinking timestamp, like the way Klipper does. Maybe the way forward is Klipper integration and just work on dual_stapper_homing… From my little knowledge about Klipper, it has CAN support, but could just as well run on USB?

I didn’t say I have a final solution, but im hoping to omit the main controller, and have the independent FOC_Stepper_Drivers connected to the PC / Gcode sender directly. Any ideas ?

From what I understand you want to run say 4 motors (steppers or 3-phase) and sync the movements, mimicking commercial off-the-shelf step/dir or speed/angle/dir controllers?

For example, you have X-Y-Z-E (xyz + extruder 3d printer) — and you need to simultaneously issue 4 signals to make them move at the same time by reading the g-code?

That’s a really hard problem to solve. You may be better off using Klipper with commercial controllers.

Isn’t that what Klipper does? It’s running on RPi and controlling external MCUs which in turn control the driver/mosfet/motor?


Yes I believe so… that’s why I guess there might be a chance to succeed with a kind of merge.

I made a semi-scientific test of TMC2660 vs. TMC2209 (w. StealthChop eneabled). Aside from StealthChop they had the same settings. First homing w. 200 mm/min then moving to X50 Y50 w. 450 mm/min.

TMC2209 don’t play nice on the Azteeg X5 GT, so they where mounted on a BTT SKR v1.3.

I believe SimpleFOC can do much better. So this is kinda a baseline for comparing future FOC stepper drivers.

1 Like

Your semi-scientific test is 99% more scientific than what my students used to do :rofl:

On a more serious note. The sound you hear is nothing compared to what will happen when you start milling. Unless you plan on milling a 30x30cm steel block in your bedroom, I think you will be OK with your current setup, unless the steppers do not have the resolution you need. Just close the door of your basement workshop and let it on full blast overnight while you sleep. Also, 450 mm/min, unless you plan on milling cheese, you will never be able to get that fast. May be 100mm/min at most for aluminum. A lot less for soft steel.

If you plan on using SimpleFOC an an educational exercise, then yes, your current setup is very loud.

However, I doubt that you can beat a commercial in-silicon hardware micro-stepper driver with SimpleFOC.

On a side note. Is the milling setup complete? Have you milled anything yet?


No no, not y’et, the enclosure is not complete. When thats done, then I hook up the liquid_cooling and brake in the spindle :sweat_smile:

That all depends on the tool (chip size, rpm etc.) If you move too slow while spinning the endmill fast, one makes dust not chips.

This Klipper concept is interesting. The code generates steps in time, which could just as well be angle :triangular_ruler: in time… I guess

Once the look-ahead process completes, the print head movement for the given move is fully known (time, start position, end position, velocity at each point) and it is possible to generate the step times for the move. This process is done within “kinematic classes” in the Klipper code. Outside of these kinematic classes, everything is tracked in millimeters, seconds, and in cartesian coordinate space. It’s the task of the kinematic classes to convert from this generic coordinate system to the hardware specifics of the particular printer.

Klipper uses an iterative solver to generate the step times for each stepper. The code contains the formulas to calculate the ideal cartesian coordinates of the head at each moment in time

Edit: Contemplating this —> The Klipper repo has SAMD support, which in the ordinary perception of things, would make that MCU a main board controlling stepper drivers or sub_drivers possibly controlling each axis, but still through a stepper driver.

What if that MCU itself was moving a stepper through SimpleFoc. It really is “just” a matter of translating the move in time to a FOC execution strategy. Acceleration, speed, moment in time

def units_in_radians(self):
# Returns true if distances are in radians instead of millimeters
return self._units_in_radians

Just realized there is already someone in space/time who did some coding

SimpleFoc is mentioned in there. Anyone with experience with this plz enlighten us!!?

From what I’m reading they are using only the hardware. It has nothing to do with SimpleFOC. Which means this would work with any other board which is pin compatible.

Hehe… send some pictures and don’t get hurt. I was very serious about cheese. Start with a very soft material else you will hurt yourself.

Question, when you manage to get it going, what do you plan on milling? Can you mill aluminium?


Sorry to interrupt the conversation. But why not use stepper motors and an esp32 controller with grbl firmware for a hobbyist machine? I also have tb6600 motor drivers


1 Like

Ok, good for you having tb6600 drivers, what’s so special about those ? You tell me, why should one use a ESP32 ?

Cool video, SHAFT!

nothing special. Just cheap)))


Its weird, 720mm/min seems like a magic number for TMC stepper drivers running NEMA23. I had some issues with the motors stalling at higher speeds. So I took off the belt and ran the motor at the same speeds and the stall still happened around 500 mm/min (4:1 gearing). Then I disabled StealthChop, and now I can achieve 720mm/min without stalling but with considerable louder motors ? In Marlin there is a #define HYBRID_THRESHOLD setting, I might try that.

These issues, should in theory be non-existing in a FOC driven stepper, if the MCU can handle the calculations and the bridges are fast enough, combined with a good 14bit encoder or some clever BEMF circuit.

Edit: mm/min not mm/s

Since my setup is geared 4:1 with a 8mm pitch lead screw one rotation from the stepper is 2mm which translated to a max rpm 720mm/min / 2mm = 360 rpm… (770mm/min starts to cause the issue, so running my TMC2660 at max 30v (Max) could most likely reach a 25% increase.

Maybe this is related to inductance ?

For future reference, this one had the same issue and found that upgrading from 24v to 36 did the trick… Stalling RPM for High Torque Stepper? | OpenBuilds

In that regard, then going for TMC5160, which dependent on FETs, can tolerate 60v, would make a huge difference. But still open looop and probably not with StealthChop at those speeds. Then the limiting factor is suddenly the main board voltage rating (most likely caps ratings).

If running a Klipper install on a linux machine or RPi, without a mainboard, but with SimpleFOC stepper drivers, higher voltage would be entirely dependent on the controller design ( FETs, caps etc.). 48v could be a good target voltage for FOC stepper driver, running standard NEMA23 for CNC purposes.

Im starting to understand why one would use TB6600 or create a ESP32 main/sub_driver rated for higher voltage. All though a S-FOC stepper driver will still be awesome…

Great educational vid about tools and feed´s for aluminum