Any chance this coming to Duet (phase stepping)?

T3P3Tony

@Egon-Net has anyone done an investigation to see what the Prusa firmware is setting on the TMC2130s?

gloomyandy

@Egon-Net It's worth reading the full thread, in particular this post:

I dug up an image from the first Phase Stepping tests where we found the worst motors we had in the factory. 
Can you recognize which one is with and which one is without the Phase Stepping? Keep in mind that on the production
 XLs the difference won't be that visible if at all - we test 100% of the motors going out since the start of the production
 to be pretty much perfect. But the results from this test are just too cool not to share!

Having said that a lot of folks are reporting that the motors are smoother and quieter with it enabled, so may be worth having. Not sure if Prusa have released the source with thsi change in it or not. If previous firmware source releases are anything to go by it will be one big check-in with no commit details. You might think they are trying to make it hard for folks to understand what they are doing.

jay_s_uk

@gloomyandy looks like the source code for 6.0.0 alpha hasn't been released yet

T3P3Tony

@jay_s_uk

https://github.com/prusa3d/Prusa-Firmware-Buddy/releases/tag/v6.0.0-alpha

It has the source code attached, and the list of commits is here:
https://github.com/prusa3d/Prusa-Firmware-Buddy/compare/v6.0.0-alpha...master

someone just needs to trawl through and see what they are doing.

timschneider

@T3P3Tony
https://github.com/prusa3d/Prusa-Firmware-Buddy/commit/70b91ceb8dd3e3858e79748ecc3024c6fd5bc540

0

wavexx committed to prusa3d/Prusa-Firmware-Buddy

Merge remote-tracking branch Phase Stepping

Authors:

Jan Mrázek<email@honzamrazek.cz>
Yuri D'Elia<wavexx@thregr.org>
Lukáš Hejl<hejl.lukas@gmail.com>

gloomyandy

@T3P3Tony It looks to me like it is doing direct control of the coil currents by manipulating the TMC2130 XDIRECT register via fast and frequent SPI updates. I'm not sure if that feature is available on anything other than tmc2130 devices. The actual timing of the coil currents seems to be using a table generated offline by a python program based on accelerometer data.

T3P3Tony

@timschneider thanks.

Having a look about in the code I see there is a lookup table to store the corrections:
https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/v6.0.0-alpha/lib/Marlin/Marlin/src/feature/phase_stepping/lut.hpp

The 2130 has the ability to have a Sine-Wave lookup table programmed into it (see section 19 of the datasheet) so my initial expectation was that they would be programming this. however I also see a lot of references to XDirect mode. which is different.

e.g. https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/v6.0.0-alpha/lib/Marlin/Marlin/src/feature/phase_stepping/phase_stepping.cpp#L359

//Swapping coils isn't a mistake - TMC in Xdirect mode swaps coils
stepper.coil_A(axis_state.last_currents.b);
stepper.coil_B(axis_state.last_currents.a);
stepper.direct_mode(true);

This is the same sort of mode as we use in the 2160s in closed loop mode on the Duet 3 1HCL and Motor23CL. - the coil currents are computed directly (by the firmware) not set by the TMC.

Digging further there appears to be a difference in operation based on "burst stepping" (not sure what that is). for example:
https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/v6.0.0-alpha/lib/Marlin/Marlin/src/feature/phase_stepping/phase_stepping.cpp#L591

#if HAS_BURST_STEPPING()
    axis_state.phase_correction = current_lut.get_phase_shift(new_phase);
    int shifted_phase = normalize_motor_phase(new_phase + axis_state.phase_correction);
    int steps_diff = phase_difference(shifted_phase, axis_state.driver_phase);
    burst_stepping::set_phase_diff(axis_enum, steps_diff);
    axis_state.driver_phase = shifted_phase;
#else
    auto new_currents = current_lut.get_current(new_phase);
    int c_adj = current_adjustment(axis_index, mm_to_rev(axis_enum, physical_speed));
    new_currents.a = new_currents.a * c_adj / 255;
    new_currents.b = new_currents.b * c_adj / 255;
    if (new_currents != axis_state.last_currents) {
        spi::set_xdirect(axis_index, new_currents);
        axis_state.last_currents = new_currents;
    }
#endif

Someone who understands whats going on better than me would need to have a further dig into the code to see if they are actually programming the LUT on the TMC, and onliny using X direct mode to work around issues with enabling/disabling the mode

In addition

There are a bunch of new gcodes to manage it, (interesting that apparently there is a gcode to modify the lookup tables manually):
https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/v6.0.0-alpha/lib/Marlin/Marlin/src/gcode/feature/phase_stepping/M970-M977.cpp

Also worth noting It looks like this can be applied independently of input shaping, the implementation caused changes to pressure advance as well as input shaping code.

T3P3Tony

@gloomyandy thanks, our replies crossed. I had not looked at how the calibration worked to populate the LUT. Its interesting to see they are using XDirect to do this similar to what we do on the 2160 for closed loop control, so I wonder what is not good enough about the Sine-Wave lookup table which appears to be a similar concept?

XDirect is called SPI direct on the 2160. AFAIK they are the same thing.

gloomyandy

@T3P3Tony From a very quick look the burst stepping stuff seems to be a way to generate step pulses on gpio pins using DMA output. It looks to me that this is an alternate to using XDIRECT and seems to basically force the stepper into 256 microstep mode and then generates the steps using this DMA code. There seems to be some sort of adjustment of the step timing based on the "phase". I've not been able to work out which implementation is actually being used.

T3P3Tony

@gloomyandy ahh, right so sending a burst of microsteps at 256 microstepping with variable gaps between them to mimic the phase shifted waveform?

gloomyandy

@T3P3Tony That would be my guess, but it would really be a guess, I've not looked that closely at it.

PenguinAkiko

I checked the code and it is consistent with your guess. Automatic calibration uses DFT to determine frequency and amplitude, and the golden section search algorithm iterates.
Without developers have no chance.