Input Shaping Polar 3D printer

General Discussion
1

Basic Information:

Printer Model: DIY Polar printer
MCU / Printerboard: BTT SKR Pico
Host / SBC: Raspberry Pi 2
klippy.log: klippy.log (82.9 KB)

I’ve build a polar 3d printer, everything works fine, except input shaping.
To be more specific: Input shaper works in the first quadrant of the carthesian system (X and Y positive), but as soon as it moves beyond that, klipper will raise a “Internal error in stepcompress” error. My test file (
Quadrant_Test.gcode (88 Bytes)) stops at the second line.

Does anybody has an idea how to fix it, or is it simply not possible with a big rewrite of the code?

Thx for you help!

2

Well, it should work, in a way, it does not care if it is a + or - cartesian.
From a high-level point of view, something went wrong, because the produced step compress data is invalid.
Input shaper only modifies kinematic output, so, I guess, if you can move everywhere without input shaper and only after enabling it, something is broken, then it is a root cause, I think.

I see you have forked Klipper and made changes: Git version: '4e636082-dirty'

It would be helpful if you either reproduce it on an unmodified Klipper
or at least make changes in a way, that when someone opens your fork, it would be crystal clear what has been changed: Commits · Neelix96/klipper · GitHub

3

Yeah I thought so, therefore the error was so strange for me.

Yes, I updated the polar.py in the kinematics folder and added an extra module, but before the test, I removed all changed locally and updated everything to the current klipper version. I pretty sure nothing was non-standard, but I can redo it with main klipper, if you want to make sure.

4

I quickly reinstalled klipper on my machine, so it’s an up-to-date, pristine klipper. Sadly the problem remains. Here the updated klippy.log:
klippy.log (84.7 KB)

1 Like
5

You are right, I can reproduce it with input shaper enabled

printer.cfg 
[mcu]
serial = /dev/serial/by-id/usb-Klipper_rp2040_E6625887D3369632-if00
restart_method = command

[printer]
kinematics = polar
max_velocity = 80
max_accel = 2000
max_z_velocity = 25
max_z_accel = 30

[input_shaper]
shaper_freq_x = 50
shaper_freq_y = 50
shaper_type = mzv

[stepper_bed]
step_pin = gpio6
dir_pin = gpio5
enable_pin = !gpio7
microsteps = 128
gear_ratio = 160:16

[stepper_arm]
step_pin = gpio11
dir_pin = gpio10
enable_pin = !gpio12
microsteps = 256
rotation_distance = 40
endstop_pin = gpio4
homing_retract_dist = 10
position_endstop = 107.2
position_max = 109
homing_speed = 50

[stepper_z]
step_pin = gpio19
dir_pin = gpio28
enable_pin = !gpio2
microsteps = 256
rotation_distance = 40
gear_ratio = 80:16
endstop_pin = ^gpio25
position_min = -10.0
position_max = 190
homing_speed = 20
homing_positive_dir = True
position_endstop = 185.150

[extruder]
step_pin = gpio14
dir_pin = gpio13
enable_pin = !gpio15
microsteps = 64
full_steps_per_rotation = 200
rotation_distance = 0.98
gear_ratio = 10:58
nozzle_diameter = 0.4
filament_diameter = 1.75
max_extrude_only_distance = 500
max_extrude_only_velocity = 120
heater_pin = gpio23
sensor_type = ATC Semitec 104GT-2
sensor_pin = gpio27
min_extrude_temp = 0
min_temp = 0
max_temp = 270
max_extrude_cross_section = 5
pressure_advance = 0.05
pressure_advance_smooth_time = 0.03
control = pid
pid_kp = 24.799
pid_ki = 1.302
pid_kd = 118.106

[heater_bed]
heater_pin = gpio21
sensor_type = Generic 3950
sensor_pin = gpio26
min_temp = 0
max_temp = 100
control = pid
pid_kp = 59.636
pid_ki = 2.469
pid_kd = 360.053

[multi_pin cooling_fans]
pins = gpio20, gpio17

[fan]
pin = multi_pin:cooling_fans
kick_start_time = 0.2

[heater_fan hotend_fan]
pin = gpio18
heater = extruder
heater_temp = 50.0

[gcode_arcs]
resolution = 1.0

$ python3 klippy/klippy.py test/klippy/polar_new.cfg -i test/klippy/polar.test -d out/klipper.dict -o test.serial -v
INFO:root:Starting Klippy...
INFO:root:Start printer at Mon Feb 17 20:26:56 2025 (1739820416.9 15040.2)
INFO:root:Extruder max_extrude_ratio=2.078758
INFO:root:Loaded MCU 'mcu' 120 commands (v0.12.0-466-g3f1927e0 / gcc: (Arch Repository) 14.2.0 binutils: (GNU Binutils) 2.43)
MCU 'mcu' config: ADC_MAX=4095 BUS_PINS_i2c0a=gpio0,gpio1 BUS_PINS_i2c0b=gpio4,gpio5 BUS_PINS_i2c0c=gpio8,gpio9 BUS_PINS_i2c0d=gpio12,gpio13 BUS_PINS_i2c0e=gpio16,gpio17 BUS_PINS_i2c0f=gpio20,gpio21 BUS_PINS_i2c0g=gpio24,gpio25 BUS_PINS_i2c0h=gpio28,gpio29 BUS_PINS_i2c1a=gpio2,gpio3 BUS_PINS_i2c1b=gpio6,gpio7 BUS_PINS_i2c1c=gpio10,gpio11 BUS_PINS_i2c1d=gpio14,gpio15 BUS_PINS_i2c1e=gpio18,gpio19 BUS_PINS_i2c1f=gpio22,gpio23 BUS_PINS_i2c1g=gpio26,gpio27 BUS_PINS_spi0_gpio0_gpio3_gpio2=gpio0,gpio3,gpio2 BUS_PINS_spi0_gpio16_gpio19_gpio18=gpio16,gpio19,gpio18 BUS_PINS_spi0_gpio20_gpio23_gpio22=gpio20,gpio23,gpio22 BUS_PINS_spi0_gpio4_gpio3_gpio2=gpio4,gpio3,gpio2 BUS_PINS_spi0_gpio4_gpio7_gpio6=gpio4,gpio7,gpio6 BUS_PINS_spi0a=gpio0,gpio3,gpio2 BUS_PINS_spi0b=gpio4,gpio7,gpio6 BUS_PINS_spi0c=gpio16,gpio19,gpio18 BUS_PINS_spi0d=gpio20,gpio23,gpio22 BUS_PINS_spi1_gpio12_gpio15_gpio14=gpio12,gpio15,gpio14 BUS_PINS_spi1_gpio24_gpio27_gpio26=gpio24,gpio27,gpio26 BUS_PINS_spi1_gpio8_gpio11_gpio10=gpio8,gpio11,gpio10 BUS_PINS_spi1a=gpio8,gpio11,gpio10 BUS_PINS_spi1b=gpio12,gpio15,gpio14 BUS_PINS_spi1c=gpio24,gpio27,gpio26 CLOCK_FREQ=12000000 MCU=rp2040 PWM_MAX=255 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
INFO:root:Sending MCU 'mcu' printer configuration...
INFO:root:Configured MCU 'mcu' (500 moves)
DEBUG:root:Running full garbage collection and freezing
INFO:root:Unknown command:"# TEST"
INFO:root:Unknown command:"CONFIG ../../"
INFO:root:Unknown command:"DICTIONARY"
DEBUG:root:; Start by homing the printer.
DEBUG:root:; Z / X / Y moves
DEBUG:root:; Delayed moves
DEBUG:root:; diagonal moves
DEBUG:root:; extrude only moves
DEBUG:root:; regular extrude move
DEBUG:root:; Multiple rotations
ERROR:root:b'stepcompress o=0 i=0 c=91 a=0: Invalid sequence'
ERROR:root:b'stepcompress o=0 i=0 c=91 a=0: Invalid sequence'
ERROR:root:Internal error on command:"G1"
6

Unfortunately, I’m not qualified to help you with that.
I can only suggest you dig around C code and see what happens in kin_shaper.
Looks like there is some math issue.

From a high-level point, itersolver gets kinematic calculation per stepper motor from kin_polar.
With enabled input shaper, itersolver gets calculation from input shaper, which gets calculation from kin polar and applies modifications to them.

I hope the test above should help you a little with local debugging.

1 Like
7

Thx for the validation and the tips!
Looks like it’s time to learn some C :smiley:

Of course: if someone has ideas, I’m open for suggestions

8

Maybe @dmbutyugin has an idea on why that would be?

-Kevin

9

I very briefly looked at it, and I suspect I understand what is going on. Input shaper allocates its own stepper_kinematics, but it does not forward post_cb in input_shaper_set_sk, which is only being used by polar kinematics, and so polar_stepper_angle_post_fixup never gets called by itersolve as a result. I have not yet validated that this resolves the issue though, I’ll do that in the next couple of days and if yes, I’ll submit a PR with this trivial fix.

3 Likes
10

OK, unfortunately the fix ended up more involved than I initially thought - since polar kinematics uses commanded_pos from stepper_kinematics for internal calculations, this one also needs to be forwarded to the original kinematics. But I think I managed to get it to work. @Neelix could you check if this branch fixes polar kinematics for you? At least it fixes the simple test posted here that I had at hand.

2 Likes
11

Thx for the quick fix!
I will test it next weekend.

12

It works perfectly! Thanks a lot!

2 Likes
13

Great, I created a PR to fix this bug in the mainline.

2 Likes
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.