X axis homing direction inverted when tuning pressure advance?

General Discussion
1

Basic Information:

Printer Model: Custom build bed slinger based on Ender 3 (but so heavily modified to effectively be a new machine)
MCU / Printerboard: SKR E3 Mini v3
klippy.log (2.9 MB)

New install of Klipper using the KIAUH tool, everything is working and I can print functional parts. I am currently going through the tuning process and trying to set up pressure advance.

I’m following the instructions at Pressure advance - Klipper documentation - if I reboot the printer it will home correctly. I can run SET_VELOCITY_LIMIT SQUARE_CORNER_VELOCITY=1 ACCEL=500 and again it will home correctly, but if I also run TUNING_TOWER COMMAND=SET_PRESSURE_ADVANCE PARAMETER=ADVANCE START=0 FACTOR=.005 then when a G28 is issued as part of the start gcode from the print, or by sending directly, the X axis moves in the wrong direction and crashes into the end of its travel, at which point I have to hard stop everything so I’ve not determined whether this also happens with the other axes.

This feels like a bug - hard to see why the TUNING_TOWER command above should have any effect on the direction of motion defined in the printer.cfg?

Cheers,

Tom

2

Hello @tomoinn !

Does that also happen when you disable PA?

Or have you accidentally removed the “!” in front of the PB12 in [stepper_x]?

3

Hi - I’ve not tried disabling PA entirely no, but it would still seem strange that that would affect the direction of motion? I’ll check tomorrow just in case.

The stepper configuration is correct, this printer isn’t a standard E3, and it is currently able to print as expected, it’s only when doing this tuning process that a problem manifests.

4

I found configs of the SKR E3 with this settings:

[stepper_x]
step_pin: PB13
dir_pin: !PB12                   # <-----------------
enable_pin: !PB14
microsteps: 16
rotation_distance: 40
endstop_pin: ^PC0
position_endstop: 0
position_max: 235
homing_speed: 50
5

As @EddyMI3D indicated, verify your settings.
This is the first report of such kind I see in over 3 years following the project. Would be very surprised if this is a bug as I used this command countless times myself on various printers.

6

Thanks everyone - turned out not to be the problem I thought it was! I’m using sensorless homing, and setting the velocity limit appears to have caused that to trigger incorrectly. That meant when the printer went to Z home it moved in a way that looked like an incorrect X homing move. I’ve reduced the sensitivity and now it’s behaving correctly. I did think it was a very weird problem!

Cheers,

Tom

1 Like