[Grbl_Esp32 Issue#471] Question: ESP23 -> SPI -> 4 * Trinamic 5160: How much RPM can I get from that configuration?

#1 – bdring 于 2020-07-06

Grbl_ESP32 can send steps up to about 120kHz. Many stepper motors will have trouble going that fast. Torque falls off with speed quickly. Be sure to check the curve for your motor.

#2 – BassMatiFreecad 于 2020-07-06

Wow — that’s a quick response! Indeed I don’t expect the stepper will reach that speed, I just wanted to make sure that the bottleneck is not the controller.

Another question: The Trinamic 5160s have an internal 6 point ramp motion controller. What do you think: Can we modify the GRBL kernel to make use of that feature? I have read about GRBL internals, the motion planner produces a low-level list of segments that (I believe) are fed into a timer/pulse/comparator peripheral to produce the step signals for the axes. My idea is to feed these motion segment list via SPI into the Trinamics instead.

What is your gut feeling, is that doable, or am I dreaming in the clouds? And if so, can I hope for some help to implement it?

#3 – MitchBradley 于 2020-07-06

The SPI connection to the trinamics is mainly used for static configuration and relatively low-speed operations like homing. Using it for real-time operations is probably not a good idea.

On another project (g2core), the idea of using the 5160 motion controller came up. TMC told those developers that the internal motion controller was mainly suitable for single-axis machines.

When you think about the problems of making the tool trace a precise n-dimensional path, that gets very difficult if each motor is independently applying its own ramp. The motion planner needs to maintain consistent velocities across the entire set of motors, so it must consider accelerations across the set for each segment.

#4 – bdring 于 2020-07-06

I looked into that a while ago. There is a an old fork of Marlin that did that. I don’t think it went anywhere.

It is not worth the effort and you might lose/break some features like realtime feed override. You also need to sync all the clocks, so it would require custom hardware.

#5 – BassMatiFreecad 于 2020-07-06

> The motion planner needs to maintain consistent velocities across the entire set of motors,
> so it must consider accelerations across the set for each segment.

Yes, this this what GRBLs motion planner already does, using a six(?)-stage lookahead strategy or buffer. The outcome is a set of linear motion segments, coordinated between all axes, taking their acceleration capabilities into account, and thereby generates ramps that are limited by the weakest in the set. I can’t see no show stopper here. The steps over time curves should (and must) be the same, regardless of where the step pulses are generated.

A whole different can of worms could be opened if the axes are driven in a closed loop configuration, where a a load could (at least theoretically) change the pulse timing. But I should first read the datasheets again before speculating.

> The SPI connection … is relatively low-speed

That’s the point, I guess. Sharp corners in the trajectory would create many small segments for each axis, which must be executed quite fast, one after the other.

Anyway, thanks a lot for your input and pointers, I’ll will think more about it.