Klipper: MCU 'mcu' shutdown: Stepper too far in past??????

[robustini]

Hi @KevinOConnor, this is getting boring and it often happens to me, when I am sure that the speeds he could sustain are certainly higher, with MK4duo (MarlinKimbra) I go much faster and never a block.
Could you give me a logical explanation for the problem?

klippy.log

[BlackStump]

I am sure you would have less problems if you set your microsteps to 16 with interpolation, 64 microsteps achieves nothing apart from taxing your mcu and not getting any more positional accuracy over 16.

[robustini]

I agree, but with other firmware with the same parameterization the MCU problem does not exist.

[KevinOConnor]

You've requested a move that exceeds the maximum number of steps per second that the micro-controller can execute. The reason you don't get an error on other firmware is that these other firmware ignore the problem (the step rate will become slower and unsynchronized which results in poor print quality, and no feedback is given to indicate what the source of that poor quality is).

The standard way to solve this is to reduce your microstepping or reduce print speed.

If you are exclusively using trinamic stepper drivers, then you could try compiling the micro-controller code with a step delay of zero (it's in the low level options of "make menuconfig"). With a step delay of zero on a sam3x8e, the micro-controller can obtain higher step rates. Even with this option, though, the step rate you've requested may be too high for the sam3x8e.

-Kevin

[robustini]

Step delay to zero produces loss of steps.
I solved it by lowering the msteps to 16, leaving interpolation and StealthChop active.

[KevinOConnor]

Okay, glad it is solved.

FYI, a sam3x8e should not have had an issue with a step delay of zero if all stepper motor drivers are trinamic drivers. If this was not the case, feel free to attach a log from the event. (Specifically, while the printer is not moving, issue GET_POSITION followed immediately by DUMP_TMC STEPPER=stepper_x, run the problematic print, and then while the printer is not moving issue the GET_POSITION/DUMP_TMC commands again; provide the log containing the session.)

-Kevin

[robustini]

Same gcode "G28 and G1 X0 Y0 Z20" on my delta, the first with step pulse 0 and the second with the default (2).
See the height of the nozzle, in first image is over 70 mm from the bed and a little shifted in X-/Y-, while in the second image it is correctly 20 mm, perfect centered.
Same gcode, same cfg, only changed the step pulse, compiled and flashed the firmware board... and now? :-)
Two identical delta printer, one only a little small, same issue.
Board RuRamps V1.3 (Due), five TMC2130 in SPI.

klippy.log

[KevinOConnor]

That's odd. It's possible that board has a filter or level-shifter on the step pin line which can't handle the shorter step pulse timing.

FYI, the log you posted doesn't have the GET_POSITION/DUMP_TMC commands so I can't confirm that the step pulses were lost, but your description certainly seems to indicate that is the problem.

Cheers,
-Kevin

[robustini]

So strange @KevinOConnor , with MK4duo i've this settings and work fine.

[KevinOConnor]

FWIW, a minimum step pulse of zero does not actually mean zero time (which wouldn't be a pulse at all). On Klipper a zero step duration on sam3x8e would be ~24 cycles or ~286ns, which is well within the specifications of the tmc2130 driver. I don't know what the actual pulse times would be on other firmware.

-Kevin

[KevinOConnor]

I'm going to close this as it appears the original issue was resolved (the error is due to requesting speed that is too high).

-Kevin