STM32F407 support?

[towe96]

Biqu has just released the SKR Pro: https://www.aliexpress.com/item/33042699158.html

It appears to be very potent board, with expansive expandability, 6 stepper sockets, and an STM32F407 MCU. I think it's fair to say it's the single best board ever released as of this date.

Is support for the SKR Pro's MCU planned?

[tiaanv]

Nope... No improvement:

v0.7.0-797-gc3f5fbc-20190830_152210-octopi

as per @MrKekson suggestion: access my PI if it can help. I am ready to reset and do what you need. You can mess around to your heart's content. I will start from scratch at some stage in any event.

If you have some sort of chat /messaging set up, we can chat in realtime. and I can be your physical presence, you send me a email if you like for details.

I have sent you my pi login details via email.

[KevinOConnor]

Nope... No improvement:

Okay, thanks.

as per @MrKekson suggestion: access my PI if it can help

Thanks, but there's little I can do remotely right now.

FWIW, I did find a couple of errors in the usb code - they are now in the latest Klipper master branch. I don't have much hope that it will help the stm32f407 though.

-Kevin

[KevinOConnor]

I tracked this down to what appears to be a chip errata on the stm32f407. Should be fixed now (commit c380d463).

-Kevin

[KevinOConnor]

I've put together an example config for the SKR Pro: https://github.com/KevinOConnor/klipper/blob/work-skr-20190831/config/generic-bigtreetech-skr-pro.cfg

Let me know if this config works or not.

-Kevin

[tiaanv]

I compared your config to mine, and it looks very similar. I can't directly test yours since my pins maps are slightly different due to dual Z.

I think if not 100% correct it most definitely represents the pins according to SKR PRO Manual/pin map.

[tiaanv]

Not sure if this belongs here, Difficuilt to tell if this is a TMC2209 issue, or a SKR PRO issue, I unfortunately don't have another board to test with. I can confirm they work 100% with the board with Marlin.

FYI: If I remove the TMC config sections the controller starts up, and everything, including the steppers, work beautifully. Considering the main goal here. THAT'S A WIN!!! Great job Kevin

CONFIG

# Tiaan's Config for SKR PRO 1.1
# STM32F407 with a "32KiB bootloader".

[stepper_x]
step_pin: PE9
dir_pin: PF1
enable_pin: !PF2
step_distance: .005
endstop_pin: PB10
position_endstop: 0
position_max: 260
homing_speed: 50

[stepper_y]
step_pin: PE11
dir_pin: PE8
enable_pin: !PD7
step_distance: .005
endstop_pin: PE12
position_endstop: 0
position_max: 280
homing_speed: 50

[stepper_z]
step_pin: PE13
dir_pin: PC2
enable_pin: !PC0
step_distance: .00125
endstop_pin: probe:z_virtual_endstop
position_endstop: 0.5
position_min: -5
position_max: 200

[stepper_z1]
step_pin: PE14
dir_pin: PA0
enable_pin: !PC3
step_distance: .00125

[bltouch]
sensor_pin: PA2
control_pin: PA1
x_offset: -27.0
z_offset: 1.2

[z_tilt]
z_positions:    0,156
        260,156
points:     0,156
        260,156
retries:    3
retry_tolerance: 1

[homing_override]
gcode:
    G90 ; Use absolute position mode
    G1 Z10 ; Move up 10mm
    G28 X Y
    G1 X150 Y150 F6000 ; Change the X and Y coordinates to the center of your print bed
    G28 Z
set_position_z: 0.0

[gcode_macro START_PRINT]
default_parameter_BED_TEMP: 55
default_parameter_EXTRUDER_TEMP: 220
gcode:
    # Start bed heating
    M140 S{BED_TEMP}
    # Use absolute coordinates
    G90
    # Reset the G-Code Z offset (adjust Z offset if needed)
    SET_GCODE_OFFSET Z=0.0
    # Home the printer
    G28
    #Z Tilt Adjustment
    Z_TILT_ADJUST
    # Move the nozzle near the bed
    G1 Z5 F3000
    # Move the nozzle very close to the bed
    G1 Z0.15 F300
    # Wait for bed to reach temperature
    M190 S{BED_TEMP}
    # Set and wait for nozzle to reach temperature
    M109 S{EXTRUDER_TEMP}

[gcode_macro END_PRINT]
gcode:
    # Turn off bed, extruder, and fan
    M140 S0
    M104 S0
    M106 S0
    # Move nozzle away from print while retracting
    G91
    G1 X-2 Y-2 E-3 F300
    # Raise nozzle by 10mm
    G1 Z10 F3000
    G90
    G1 X260 Y280 F6000
    # Disable steppers
    M84

[extruder]
step_pin: PD15
dir_pin: PE7
enable_pin: !PA3
step_distance: 0.00075
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PB1
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF3
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
pressure_advance: 0.0
#pressure_advance: 0.0
pressure_advance_lookahead_time: 0.010

[heater_bed]
heater_pin: PD12
sensor_type: EPCOS 100K B57560G104F
sensor_pin: PF6
control: pid
pid_Kp: 94.9
pid_Ki: 4.187
pid_Kd: 538
min_temp: 0
max_temp: 130
pwm_cycle_time: 0.1
#control: watermark

[heater_fan nozzle_fan]
pin: PC8
heater: extruder
heater_temp: 50.0
fan_speed: 1.0

[fan]
pin: PE5

#TODO
#[output_pin case_lights_pin]
#pin: P2.7
#pwm: True
#value: 100
#   Silent at power on, set to 1 if active low.
#shutdown_value: 0
#   Disable at emergency shutdown (no PWM would be available anyway).
#cycle_time: 0.0001
#   PWM frequency : 0.001 = 1ms will give a base tone of 1kHz
#scale: 100

[mcu]
serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00

[printer]
kinematics: corexy
max_velocity: 500
max_accel: 4000
max_z_velocity: 60
max_z_accel: 60

########################################
# TMC2209 configuration
########################################

[tmc2209 stepper_x]
uart_pin: PC13
tx_pin: PE4
microsteps: 16
run_current: 0.500
hold_current: 0.300
stealthchop_threshold: 250

[tmc2209 stepper_y]
uart_pin: PE3
tx_pin: PE2
microsteps: 16
run_current: 0.500
hold_current: 0.300
stealthchop_threshold: 250

[tmc2209 stepper_z]
uart_pin: PE1
tx_pin: PE0
microsteps: 16
run_current: 0.500
hold_current: 0.300
stealthchop_threshold: 30

[tmc2209 stepper_z1]
uart_pin: PD4
tx_pin: PD2
microsteps: 16
run_current: 0.500
hold_current: 0.300
stealthchop_threshold: 30

[tmc2209 extruder]
uart_pin: PD1
tx_pin: PD0
microsteps: 16
run_current: 0.500
hold_current: 0.400
stealthchop_threshold: 5

########################################
# EXP1 / EXP2 (display) pins
########################################

[board_pins]
aliases:
    # EXP1 header
    EXP1_1=PG4, EXP1_3=PD11, EXP1_5=PG2, EXP1_7=PG6, EXP1_9=<GND>,
    EXP1_2=PA8, EXP1_4=PD10, EXP1_6=PG3, EXP1_8=PG7, EXP1_10=<5V>,
    # EXP2 header
    EXP2_1=PB14, EXP2_3=PG10, EXP2_5=PF11, EXP2_7=PF12,  EXP2_9=<GND>,
    EXP2_2=PB13, EXP2_4=PB12, EXP2_6=PB15, EXP2_8=<RST>, EXP2_10=PF13
    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "spi2"

# See the sample-lcd.cfg file for definitions of common LCD displays.

# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
#[display]
#lcd_type: st7920
#cs_pin: P0.16
#sclk_pin: P0.15
#sid_pin: P0.18
#encoder_pins: ^P3.25, ^P3.26
#click_pin: ^!P1.30

ERROR:

TMC init error
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/extras/tmc.py", line 106, in _handle_connect
    self._init_registers()
  File "/home/pi/klipper/klippy/extras/tmc.py", line 101, in _init_registers
    self.mcu_tmc.set_register(reg_name, val, print_time)
  File "/home/pi/klipper/klippy/extras/tmc_uart.py", line 222, in set_register
    self.ifcnt = ifcnt = self._do_get_register("IFCNT")
  File "/home/pi/klipper/klippy/extras/tmc_uart.py", line 210, in _do_get_register
    "Unable to read tmc uart '%s' register %s" % (self.name, reg_name))
CommandError: Unable to read tmc uart 'stepper_x' register IFCNT
Config error
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/klippy.py", line 138, in _connect
    cb()
  File "/home/pi/klipper/klippy/extras/tmc.py", line 112, in _handle_connect
    raise self.printer.config_error(str(e))
Error: Unable to read tmc uart 'stepper_x' register IFCNT
Resetting prediction variance 213759.015: freq=167175172 diff=8946951 stddev=144240.621
Unable to read tmc uart 'stepper_x' register IFCNT
Once the underlying issue is corrected, use the "RESTART"
command to reload the config and restart the host software.
Printer is halted

[KevinOConnor]

Make sure you have motor power enabled when starting Klipper (the tmc drivers wont respond if they don't have motor power). Other things to check are that the uart jumpers are correct on the board and that the board's uart pin is routed to the correct uart pin on the stepstick.

If you still have issues, please attach the full klipper log (see https://www.klipper3d.org/Contact.html ).

-Kevin

[KevinOConnor]

FYI, there was an issue with the recent USB support that could cause sporadic retransmits. This should now hopefully be fixed (commit 4fa41d9c). @tiaanv - could you verify this code on your setup?

-Kevin

[tiaanv]

Hey Kevin.

I was doing the "happy dance" now. As you know, for me, this manifested in my PROBING. I uploaded the firmware and did some PROBE repeatability tests.

I can confirm that the latest build definitely, if not irradicated, clearly made a positive impact. By implication, the latest firmware works in terms of retransmits.

I will do some additional tests further now, including TMC UART tests we spoke about.

THX!!! So happy.

[MrKekson]

With skr pro board, during prints klipper suddenly collapses. I have to restart the board manually to get it back. The time seems like random, happened in multiple test prints. If i have multiple klipper instances how can i extract the relevant logs?

Updated to #https://github.com/KevinOConnor/klipper/commit/4fa41d9c6165ec4ac18e1c5ce54e59c00079ea1a, testing it now.

[tiaanv]

I've only done one print to date, it ran for about 2 hours. Completed successfully. Will definately be doing some more. On the firmware before latest commit, I did come back to the board after idle for a few hours, and had to restart the klipper service and hit the manual reset button on the board to get it working again.

[MrKekson]

Saame problem with the https://github.com/KevinOConnor/klipper/commit/4fa41d9c6165ec4ac18e1c5ce54e59c00079ea1a commit. 4h print stopped on 73 %. If someone tell me how to capture the logs with a different config, (printer_xy.cfg) i can post them.

[KevinOConnor]

A log is necessary in order for me to assist. Details on obtaining the log are at https://www.klipper3d.org/Contact.html . If you've done a custom install, be sure to follow the info at: https://www.klipper3d.org/FAQ.html#can-i-run-multiple-instances-of-klipper-on-the-same-host-machine .

-Kevin

[MrKekson]

I would gladly provide logs for you. But i'm running 2 klipper and 2 octo for a good while now. And my problem is the log extactor python script filtering the log for the first klipper (printer.cfg), and not the second one (printer_xy.cfg). So should i post the entire log file, or can i filter it for the second klipper? Ah ok, so the other instance using other logs. it's 70mb, so i'll try to crop the relevant parts.

[MrKekson]

there was an error after midnight, the print started on the previous day, but that day i asembled the board, so most of the errors are not valid, since there was no temp sensor etc at the beginning. You can see klippy processing th gcode, and then suddenly nothing. FIRMWARE_RESTART does nothing, have to power cycle the board

klippy_xy.log.zip

Stats 3126667.5: gcodein=10857591 mcu: mcu_awake=0.006 mcu_task_avg=0.000011 mcu_task_stddev=0.000024 bytes_write=32829613 bytes_read=5359291 bytes_retransmit=9 bytes_invalid=0 send_seq=608596 receive_seq=608596 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=168001005 heater_bed: target=50 temp=50.0 pwm=0.557 print_time=20976.410 buffer_time=2.470 print_stall=0 extruder: target=200 temp=200.0 pwm=0.479 Stats 3126668.5: gcodein=10858032 mcu: mcu_awake=0.006 mcu_task_avg=0.000011 mcu_task_stddev=0.000024 bytes_write=32831202 bytes_read=5359554 bytes_retransmit=9 bytes_invalid=0 send_seq=608626 receive_seq=608626 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=11 stalled_bytes=0 freq=168001005 heater_bed: target=50 temp=50.0 pwm=0.383 print_time=20976.912 buffer_time=1.970 print_stall=0 extruder: target=200 temp=200.0 pwm=0.479 Stats 3126669.5: gcodein=10858064 mcu: mcu_awake=0.007 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=32832710 bytes_read=5359826 bytes_retransmit=9 bytes_invalid=0 send_seq=608655 receive_seq=608655 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=168001006 heater_bed: target=50 temp=50.1 pwm=0.345 print_time=20978.163 buffer_time=2.221 print_stall=0 extruder: target=200 temp=200.0 pwm=0.493 Stats 3126670.5: gcodein=10858396 mcu: mcu_awake=0.007 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=32835394 bytes_read=5360154 bytes_retransmit=9 bytes_invalid=0 send_seq=608701 receive_seq=608701 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=168001013 heater_bed: target=50 temp=50.0 pwm=0.437 print_time=20979.984 buffer_time=3.040 print_stall=0 extruder: target=200 temp=200.0 pwm=0.493 Stats 3126671.5: gcodein=10858396 mcu: mcu_awake=0.007 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=32835460 bytes_read=5360292 bytes_retransmit=9 bytes_invalid=0 send_seq=608706 receive_seq=608706 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=168001009 heater_bed: target=50 temp=50.1 pwm=0.307 print_time=20979.984 buffer_time=2.039 print_stall=0 extruder: target=200 temp=199.9 pwm=0.493 Stats 3126672.5: gcodein=10859008 mcu: mcu_awake=0.007 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=32837758 bytes_read=5360609 bytes_retransmit=9 bytes_invalid=0 send_seq=608747 receive_seq=608747 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=168001004 heater_bed: target=50 temp=50.1 pwm=0.360 print_time=20981.168 buffer_time=2.223 print_stall=0 extruder: target=200 temp=199.9 pwm=0.493 Stats 3126673.5: gcodein=10861218 mcu: mcu_awake=0.007 mcu_task_avg=0.000010 mcu_task_stddev=0.000019 bytes_write=32842602 bytes_read=5361082 bytes_retransmit=9 bytes_invalid=0 send_seq=608830 receive_seq=608822 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=17 stalled_bytes=0 freq=168001002 heater_bed: target=50 temp=50.1 pwm=0.413 print_time=20982.264 buffer_time=2.318 print_stall=0 extruder: target=200 temp=199.9 pwm=0.479 Stats 3126674.5: gcodein=10862153 mcu: mcu_awake=0.010 mcu_task_avg=0.000014 mcu_task_stddev=0.000054 bytes_write=32846016 bytes_read=5361552 bytes_retransmit=9 bytes_invalid=0 send_seq=608890 receive_seq=608890 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=19 stalled_bytes=0 freq=168001001 heater_bed: target=50 temp=50.2 pwm=0.222 print_time=20983.816 buffer_time=2.870 print_stall=0 extruder: target=200 temp=199.9 pwm=0.479 Stats 3126675.5: gcodein=10862861 mcu: mcu_awake=0.010 mcu_task_avg=0.000014 mcu_task_stddev=0.000054 bytes_write=32846106 bytes_read=5361694 bytes_retransmit=9 bytes_invalid=0 send_seq=608896 receive_seq=608896 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=168000998 heater_bed: target=50 temp=50.2 pwm=0.295 print_time=20983.816 buffer_time=1.868 print_stall=0 extruder: target=200 temp=199.9 pwm=0.479 Stats 3126676.6: gcodein=10864782 mcu: mcu_awake=0.010 mcu_task_avg=0.000014 mcu_task_stddev=0.000054 bytes_write=32850591 bytes_read=5362177 bytes_retransmit=9 bytes_invalid=0 send_seq=608973 receive_seq=608973 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=168000991 heater_bed: target=50 temp=50.2 pwm=0.381 print_time=20984.788 buffer_time=1.836 print_stall=0 extruder: target=200 temp=200.0 pwm=0.479 Stats 3126677.6: gcodein=10865798 mcu: mcu_awake=0.010 mcu_task_avg=0.000014 mcu_task_stddev=0.000054 bytes_write=32853660 bytes_read=5362441 bytes_retransmit=69 bytes_invalid=0 send_seq=609027 receive_seq=609012 retransmit_seq=609013 srtt=0.001 rttvar=0.000 rto=0.200 ready_bytes=431 stalled_bytes=567 freq=168000987 heater_bed: target=50 temp=50.3 pwm=0.189 print_time=20986.184 buffer_time=2.232 print_stall=0 extruder: target=200 temp=200.1 pwm=0.451 Stats 3126678.6: gcodein=10868637 mcu: mcu_awake=0.010 mcu_task_avg=0.000014 mcu_task_stddev=0.000054 bytes_write=32853660 bytes_read=5362441 bytes_retransmit=1781 bytes_invalid=0 send_seq=609027 receive_seq=609012 retransmit_seq=609027 srtt=0.001 rttvar=0.000 rto=0.800 ready_bytes=431 stalled_bytes=4251 freq=168000987 heater_bed: target=50 temp=50.3 pwm=0.189 print_time=20988.018 buffer_time=3.065 print_stall=0 extruder: target=200 temp=200.1 pwm=0.451 Stats 3126679.6: gcodein=10868637 mcu: mcu_awake=0.010 mcu_task_avg=0.000014 mcu_task_stddev=0.000054 bytes_write=32853660 bytes_read=5362441 bytes_retransmit=2637 bytes_invalid=0 send_seq=609027 receive_seq=609012 retransmit_seq=609027 srtt=0.001 rttvar=0.000 rto=1.600 ready_bytes=431 stalled_bytes=4270 freq=168000987 heater_bed: target=50 temp=50.3 pwm=0.189 print_time=20988.018 buffer_time=2.065 print_stall=0 extruder: target=200 temp=200.1 pwm=0.451 Stats 3126680.6: gcodein=10869019 mcu: mcu_awake=0.010 mcu_task_avg=0.000014 mcu_task_stddev=0.000054 bytes_write=32853660 bytes_read=5362441 bytes_retransmit=3493 bytes_invalid=0 send_seq=609027 receive_seq=609012 retransmit_seq=609027 srtt=0.001 rttvar=0.000 rto=3.200 ready_bytes=431 stalled_bytes=5638 freq=168000987 heater_bed: target=50 temp=50.3 pwm=0.189 print_time=20989.453 buffer_time=2.499 print_stall=0 extruder: target=200 temp=200.1 pwm=0.451 Stats 3126681.6: gcodein=10869984 mcu: mcu_awake=0.010 mcu_task_avg=0.000014 mcu_task_stddev=0.000054 bytes_write=32853660 bytes_read=5362441 bytes_retransmit=3493 bytes_invalid=0 send_seq=609027 receive_seq=609012 retransmit_seq=609027 srtt=0.001 rttvar=0.000 rto=3.200 ready_bytes=431 stalled_bytes=7408 freq=168000987 heater_bed: target=50 temp=50.3 pwm=0.189 print_time=20990.732 buffer_time=2.777 print_stall=0 extruder: target=200 temp=200.1 pwm=0.451 Timeout with MCU 'mcu' (eventtime=3126682.555561) Dumping gcode input 50 blocks Read 3126678.362361: 'N162689 G1 X141.487 Y205.159 E1910.40607105\n' Read 3126678.367428: 'N162690 G1 X140.95 Y205.034 E1910.4244195\n' Read 3126678.371783: 'N162691 G1 X138.772 Y205.016 E1910.49685110\n' Read 3126678.376611: 'N162692 G1 X138.772 Y204.216 E1910.52346110\n' Read 3126678.381425: 'N162693 G1 X150.101 Y204.216 E1910.90026104\n' Read 3126679.626708: 'N162694 G1 X150.583 Y204.087 E1910.91686102\n' Read 3126679.631730: 'N162695 G1 X150.993 Y203.677 E1910.93614109\n' Read 3126679.636300: 'N162696 G1 X151.122 Y203.195 E1910.9527498\n' Read 3126679.640477: 'N162697 G1 X151.122 Y117.437 E1913.80506109\n' Read 3126679.856604: 'N162698 G1 X150.993 Y116.955 E1913.82166105\n' Read 3126679.860698: 'N162699 G1 X150.583 Y116.545 E1913.8409498\n' Read 3126679.864967: 'N162700 G1 X150.101 Y116.416 E1913.8575496\n' Read 3126679.871201: 'N162701 G1 F1500 E1912.357549\n' Read 3126679.875458: 'N162702 G0 F15000 X151.522 Y203.24869\n' Read 3126681.064126: 'N162703 G1 F1500 E1913.857541\n' Read 3126681.068324: 'N162704 G1 F6000 X151.522 Y204.913 E1913.912922\n' Read 3126681.072593: 'N162705 G1 X151.472 Y205.269 E1913.9248797\n' Read 3126681.076820: 'N162706 G1 X151.4 Y205.447 E1913.9312698\n' Read 3126681.081058: 'N162707 G1 X150.859 Y206.243 E1913.96327101\n' Read 3126681.085429: 'N162708 G1 X148.922 Y208.996 E1914.07523110\n' Read 3126681.089619: 'N162709 G1 X148.508 Y209.474 E1914.0962699\n' Read 3126681.094338: 'N162710 G1 X148.21 Y209.717 E1914.1090585\n' Read 3126681.098489: 'N162711 G1 X147.716 Y210.004 E1914.12805102\n' Read 3126681.102626: 'N162712 G1 X147.371 Y210.134 E1914.14031107\n' Read 3126681.107002: 'N162713 G1 X146.819 Y210.246 E1914.15905103\n' Read 3126681.111098: 'N162714 G1 X146.432 Y210.261 E1914.17193101\n' Read 3126681.115125: 'N162715 G1 X145.879 Y210.189 E1914.19048104\n' Read 3126681.119278: 'N162716 G1 X145.513 Y210.078 E1914.203282\n' Read 3126681.123825: 'N162717 G1 X145.01 Y209.835 E1914.2217881\n' Read 3126681.128093: 'N162718 G1 X144.701 Y209.615 E1914.23439101\n' Read 3126681.132226: 'N162719 G1 X144.296 Y209.217 E1914.25328104\n' Read 3126681.136771: 'N162720 G1 X144.074 Y208.909 E1914.26591110\n' Read 3126681.140960: 'N162721 G1 X143.822 Y208.411 E1914.2844799\n' Read 3126681.145523: 'N162722 G1 X143.71 Y208.045 E1914.2972104\n' Read 3126681.150467: 'N162723 G1 X143.614 Y207.382 E1914.3194898\n' Read 3126681.154573: 'N162724 G1 X143.487 Y206.689 E1914.34292107\n' Read 3126682.339854: 'N162725 M10518\n' Read 3126682.348511: 'N162726 M117 74.11p complete102\n' Read 3126682.354587: 'N162727 G1 X143.22 Y206.095 E1914.3645890\n' Read 3126682.358722: 'N162728 G1 X142.777 Y205.513 E1914.388993\n' Read 3126682.362984: 'N162729 G1 X142.276 Y205.104 E1914.4104299\n' Read 3126682.367212: 'N162730 G1 X141.623 Y204.78 E1914.4346687\n' Read 3126682.371458: 'N162731 G1 X140.998 Y204.634 E1914.4560199\n' Read 3126682.375740: 'N162732 G1 X139.172 Y204.619 E1914.51674106\n' Read 3126682.379878: 'N162733 G1 X139.172 Y204.616 E1914.51684107\n' Read 3126682.384141: 'N162734 G1 X150.154 Y204.616 E1914.88211107\n' Read 3126682.388214: 'N162735 G1 X150.79 Y204.446 E1914.90492\n' Read 3126682.392369: 'N162736 G1 X151.352 Y203.884 E1914.93044102\n' Read 3126682.396568: 'N162737 G1 X151.522 Y203.248 E1914.95233104\n' Read 3126682.402966: 'N162738 G1 F1500 E1913.452331\n' gcode state: absolute_coord=True absolute_extrude=True base_position=[0.0, 0.0, 0.0, 16305.16031] last_position=[151.522, 203.248, 8.4, 18218.61264] homing_position=[0.0, 0.0, 0.0, 0.0] speed_factor=0.0133333333333 extrude_factor=1.0 speed=20.0 Stats 3126682.6: gcodein=10870548 mcu: mcu_awake=0.010 mcu_task_avg=0.000014 mcu_task_stddev=0.000054 bytes_write=32853660 bytes_read=5362441 bytes_retransmit=3493 bytes_invalid=0 send_seq=609027 receive_seq=609012 retransmit_seq=609027 srtt=0.001 rttvar=0.000 rto=3.200 ready_bytes=431 stalled_bytes=8781 freq=168000987 heater_bed: target=50 temp=50.3 pwm=0.189 print_time=20991.137 buffer_time=2.182 print_stall=0 extruder: target=200 temp=200.1 pwm=0.451 Lost communication with MCU 'mcu' Once the underlying issue is corrected, use the "FIRMWARE_RESTART" command to reset the firmware, reload the config, and restart the host software. Printer is shutdown

Lost communication with MCU 'mcu' Once the underlying issue is corrected, use the "FIRMWARE_RESTART" command to reset the firmware, reload the config, and restart the host software. Printer is shutdown

Lost communication with MCU 'mcu' Once the underlying issue is corrected, use the "FIRMWARE_RESTART" command to reset the firmware, reload the config, and restart the host software. Printer is shutdown

Lost communication with MCU 'mcu' Once the underlying issue is corrected, use the "FIRMWARE_RESTART" command to reset the firmware, reload the config, and restart the host software. Printer is shutdown

[KevinOConnor]

there was an error after midnight

FYI, I've seen a similar error in a very long running simulation on my stm32f446 test board. I'll try to reproduce it and see if I can find the root cause.

-Kevin

[MrKekson]

happened again, same config, same error. Strange thing is yesterday i managed to run 2 5+h print. This died after maybe 1-1.5 h line 29537 klippy_xy.zip do you have any ideas how can i hunt or help you hunt this bug?

[KevinOConnor]

I've been testing a change that has been working so far (roughly 24 hours of simulations without a failure). If you want to test as well, you can grab the code on the work-stm32usb-20190912 branch.

cd ~/klipper ; git fetch ; git checkout origin/work-stm32usb-20190912 ; make ; make flash ; sudo service klipper restart

-Kevin

[MrKekson]

Will do later today!

[KevinOConnor]

FYI, I got up to 48 hours of simulations without a fault, so I went ahead and pushed the new code (commit 60ae92d1). Hopefully this solves all remaining issues with the new USB code.

-Kevin

[MrKekson]

i've installed it yesterday, and had a 5 h print, the crash did not appeared. Since it's a new board, i won't leave that printer unattended, but i'll pull the master today, and start a longer print for the weekend.

On Tue, 10 Sep 2019 at 04:11, KevinOConnor notifications@github.com wrote:

A log is necessary in order for me to assist. Details on obtaining the log are at https://www.klipper3d.org/Contact.html . If you've done a custom install, be sure to follow the info at: https://www.klipper3d.org/FAQ.html#can-i-run-multiple-instances-of-klipper-on-the-same-host-machine .

-Kevin

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/1733?email_source=notifications&email_token=AAWUDIQ7VFTU7RNAMJDO5S3QI365JA5CNFSM4HYPLMZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JSSLQ#issuecomment-529738030, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWUDIS3RYZ62VNPBF2GSWLQI365JANCNFSM4HYPLMZQ .

-- Oli

[MrKekson]

Tested on master for 2 days, seems like the mcu part is stable now. I'll update you if anything comes up. I had 0 problems on this 2 days, while printing multiple 5-14h prints, but did not needed to reset/power cycle for this 2 days. Thx for the quick fix!

[MrKekson]

After a week, i did not met the same problem, but after a longer print around the 30th hour. Klippy forgot the home coordinates. I'm at work can't attach the log, but klipper detected no error. The gcode was streaming, but every gcode was followed by a lot of home axis first message. The extruder still extruded, temperatures and fans was ok. But the print head stopped. After a print restart, the problem occured within minutes again. Restarting the board did nothing, but restarting the klipper service solved it. So it must be some error in the python side.

I'm not sure if it's related to this particular cpu, because I've experienced this problem, on other boards, but only on print start: If i reload the config a lot, sometimes it forgot to home, the command is there, but the homeing process did not start, and only the extruder was running, with the same home first message, but no other errors. I can attach the logs later on, but i've seen nothing usefull, just suddenly a lot of home first message, like klippy forgot the home positions suddenly.

I can open a ticket if the problem is not know yet, because if klipper does it midprint, it can crank out a lot of filament causing all kind of prodlems including destoying the print head.

Strange thing is, everything looks normal in this state, no errors, no console problems, just this home first messages, but all my gcode start wit a home command.

[KennethThompson]

I have been running the SKR pro using the build from the commit 60ae92d with no issues. Most of my prints have run in the 4-6 hour range, at most, so I cannot comment on extra-long builds.

I am using a Rasp Pi 3B+, SKR pro, TCM5160s and an Ender 5 platform with mostly stock parts. The SKR was a pain to wire properly & learning Klipper by fire was helpful in getting a better handle on advanced configurations.

@KevinOConnor Can you point me at a document or calculator I can use to understand max print settings based on my config? For instance, I cannot run at 256 microsteps and go above 200 mm/s, I get the error about being behind. I get the math behind it, but it would be helpful if you can direct to me a resource that helps explain how to factor various hardware & software configurations to ensure I am at or below my SKR pro's maximum capabilities.

Overall, my results are good. The attached was printed at 250 mm/s.. mostly dialed in (with pressure advance). But I have some temperature issues and some additional calibration I need to perform.

[MrKekson]

I think we are well off topic here. You can find information about the max step rates on different cpus here: https://github.com/KevinOConnor/klipper/blob/master/docs/Features.md. I do not think there is any benefits on microsteping over 64(if you gear it up, there might be, but then why not gear it down with full steps?), since your position will be off on middle steps(you loose torque you get closer to the halfstep), and you just overload the cpu without any benefit. But i don't want to convince you that it make no sense here, because this issue is not about the feed rate of the steppers.

[KennethThompson]

I think we are well off topic here. You can find information about the max step rates on different cpus here: https://github.com/KevinOConnor/klipper/blob/master/docs/Features.md. I do not think there is any benefits on microsteping over 64(if you gear it up, there might be, but then why not gear it down with full steps?), since your position will be off on middle steps(you loose torque you get closer to the halfstep), and you just overload the cpu without any benefit. But i don't want to convince you that it make no sense here, because this issue is not about the feed rate of the steppers.

Only partly off-topic. But I get what you are saying and, at the moment, I am running 16 steps with great results. That Klipper link does not answer the overall question, which I think many like myself have, which is how to translate the benchmark data into practical use. It needs to be dumbed down, for simple people like me, who want to understand how to optimize our settings to get the most of of Klipper. Like I said, I get the math of how 1 mm equals X number of instructions based on the micro-steps, but I was hoping to get a link to a document that explains the big picture as well as small-detail stuff to optimize klipper... particularly for people who are pushing the limits using SKR pros/GCs/Deuts and so on.

[KevinOConnor]

Like I said, I get the math of how 1 mm equals X number of instructions based on the micro-steps

That's basically all there is to it. I'd guess the reason you hit an error is due to the 2us minimum step time (configured under "low level" options in "make menuconfig"). With that default pulse time there is a theoretical limit of 250K steps per second on any one stepper (and a practical limit generally around 200K). If you are exclusively using Trinamic stepper motor drivers on a micro-controller then you should be able to set the pulse time to zero to avoid that limit.

but I was hoping to get a link to a document that explains the big picture as well as small-detail stuff to optimize klipper

I have not run these types of tests myself. My general understanding is that there is no gain to increasing micro-stepping beyond 16, and thus no advantage to tuning. My understanding may be wrong - if someone wishes to run the tests, demonstrate the advantages, and contribute a guide that would be great.

particularly for people who are pushing the limits using SKR pros/GCs/Deuts and so on.

FWIW, my general understanding is that it is not possible to stress these boards in a normal setup - these boards are orders of magnitude more powerful than needed.

Cheers, -Kevin

[KennethThompson]

Like I said, I get the math of how 1 mm equals X number of instructions based on the micro-steps

That's basically all there is to it. I'd guess the reason you hit an error is due to the 2us minimum step time (configured under "low level" options in "make menuconfig"). With that default pulse time there is a theoretical limit of 250K steps per second on any one stepper (and a practical limit generally around 200K). If you are exclusively using Trinamic stepper motor drivers on a micro-controller then you should be able to set the pulse time to zero to avoid that limit.

but I was hoping to get a link to a document that explains the big picture as well as small-detail stuff to optimize klipper

I have not run these types of tests myself. My general understanding is that there is no gain to increasing micro-stepping beyond 16, and thus no advantage to tuning. My understanding may be wrong - if someone wishes to run the tests, demonstrate the advantages, and contribute a guide that would be great.

particularly for people who are pushing the limits using SKR pros/GCs/Deuts and so on.

FWIW, my general understanding is that it is not possible to stress these boards in a normal setup - these boards are orders of magnitude more powerful than needed.

Cheers, -Kevin

I will be definitely setting the pulse time to zero to see how far I can push it. Klipper caught my eye when I saw a delta running at 1000 mm/s on youtube. I am on a mission to see that result (or better) with my Ender 5.. even if that means essentially replacing everything. I can't explain the obsession to see such print speeds.. other than the fact I can't afford a lambo/bugatti nor the time to rent a dyno. So my 3D printer will have to suffice.

I appreciate your comments on the micro steps. I have yet to encounter a scenario where the increased microsteps will help.. but I remain opened to be convinced by someone smarter than myself.

Overall, I think I represent a certain consumer of Klipper that is going to become more common over time..perhaps you already witnessed this. We see the benchmarks and the potential and want to take our bleeding-edge MCUs and run them at extreme speeds. Then we find out that such exercises are most similar to taking a cold shower while ripping up 100 dollar bills (an analogy most often used to describe the joy of owning a yacht/boat).

I think I may put together an article that helps to demystify klipper, mcu capabilities and hardware configurations. I have not written a technical article since 2007, but my work on wireshark dissectors is still in use today... so may it is time to shake that rust off and contribute.

[Hywelmartin]

@CalielOfSeptem I believe that the delta at 1m/s was running 1/8 microsteps, at that moment... If it was this one.. but with a AtMega..and the top speed was (theoretically, there is no speedo in Klipper) only achieved during ~3cm in the middle of the longest run on the inner perimiters I have tried 1/32 but didn't noticed any benefits for printing.. for delta calibration it would gain some benefits I believe..1/16 is the normal setup for me..

@KevinOConnor "...the pulse time to zero to avoid that limit.." is that safe for non motion axis allegro drivers(I have a stepper that actuates a brush)..

[MrKekson]

Anyone got this strange klippy lost the home midprint error? Did not experienced it before, only during print start, and since it's klippy, i'm not sure if it's board/mcu related. Experienced the homeless startup problem with ramps1.4 + arduino, 8 bit anet, this skr pro. Not with the skr 1.3 but i use that printer rarely for high temp materials. If not then i'll open up an other issue.

But the main point is, i1m running skr pro from master for a week, and the usb problem seems to be gone.

[KevinOConnor]

"...the pulse time to zero to avoid that limit.." is that safe for non motion axis allegro drivers(I have a stepper that actuates a brush)..

No, setting the pulse length to zero would not be valid if there are Allegro drivers controlled by the micro-controller.

-Kevin

[KennethThompson]

@CalielOfSeptem I believe that the delta at 1m/s was running 1/8 microsteps, at that moment... If it was this one.. but with a AtMega..and the top speed was (theoretically, there is no speedo in Klipper) only achieved during ~3cm in the middle of the longest run on the inner perimiters I have tried 1/32 but didn't noticed any benefits for printing.. for delta calibration it would gain some benefits I believe..1/16 is the normal setup for me..

@KevinOConnor "...the pulse time to zero to avoid that limit.." is that safe for non motion axis allegro drivers(I have a stepper that actuates a brush)..

That is the delta machine that got me hot on hitting 1000 mm/s print speeds. To my surprise, this thing called 'physics' has smacked me in the face. At the moment I have reached speeds in excess of 250 mm/s without losing quality- I base that statement on the fact I can successfully print objects with threads (e.g., belt tensioner). But speeds in excess of 250 mm/s are a challenge due to some physical factors of my machine and the calibration issues. In addition, I am not 100% sure how to validate whether my printer is ever reaching the top speed or if I have some other limiting factor that is resulting in an actual print speed that is less than the target. The quest continues. I will hit 1000 mm/s eventually.

[jcm11215]

after installing klipper on my bigtreetech skr pro v1.1 my printer no longer responds to octoprint movement controls and klipper states, "no section 'printer'" Does anyone know what that means?

[KennethThompson]

You are missing a config section labeled printer:

[printer] kinematics: cartesian max_velocity: 15000 max_accel: 16000 max_z_velocity: 75 max_z_accel: 750

(Those are my insane values, use at your own risk)

On Sun, Sep 29, 2019, 7:00 PM jcm11215 notifications@github.com wrote:

[image: Screenshot (11)] https://user-images.githubusercontent.com/5752853/65840828-39aa9180-e2d2-11e9-9e96-10e1fd77e63e.png after installing klipper on my bigtreetech skr pro v1.1 my printer no longer responds to octoprint movement controls and klipper states, "no section 'printer'" Does anyone know what that means?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/1733?email_source=notifications&email_token=AA4HTDPQBLSTCNLZ6WR7LRLQMEXSRA5CNFSM4HYPLMZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD74A3KY#issuecomment-536350123, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4HTDJCNXMDKFDISSTSV3LQMEXSRANCNFSM4HYPLMZQ .

[sergiocipo]

Hi, I'm tryng to install klipper on a new skr 1.1 pro. at this time i made a make menuconfig using this options: . then make clean and make to generate the klipper.bin, renamed klipper.bin in firmware.bin and moved to the sd. running lsusb on raspberry pi successfully shows the new device but the communication between host and printer doesn't work, this is my klippy.log

[KennethThompson]

Hi, I'm tryng to install klipper on a new skr 1.1 pro. at this time i made a make menuconfig using this options: . then make clean and make to generate the klipper.bin, renamed klipper.bin in firmware.bin and moved to the sd. running lsusb on raspberry pi successfully shows the new device but the communication between host and printer doesn't work, this is my klippy.log

Hmm. When you look at the SD card now, is there a firmware.cur file only? If there is a firmware.bin and a firmware.cur, it did not take. I recall the directions saying you must start the SKR pro via external power and not via USB power for the firmware to take. If you are just using USB power, time to switch the jumper on the SKR pro board off of USB power, and use an external power supply.

[sergiocipo]

on sd there is only a firmware.cur. there is link /dev/serial/by-id/ and lsusb is showing the hardware with vendor id and serial specified in the menuconfig so I guess the firmware has been correctly loaded. the board is powered by an external 24V power supply.

[sergiocipo]

ok i found it.... the link name in [mcu] serial: options was incorrect. I just pasted it into printer.cfg file.

[KennethThompson]

ok i found it.... the link name in [mcu] serial: options was incorrect. I just pasted it into printer.cfg file.

That is odd to have a mismatch like that. What was the correct ID? When I compared your log to my own, the USB name matched.

[sergiocipo]

the wrong id had 000 at the end while the right one has only 00

[jcm11215]

Everything appears to be in order and i have klipper firmware flashed to my skr pro v1.1. Can anyone decipher how to fix MCU 'mcu' shutdown: ADC out of range error? klippy.log

[sergiocipo]

Everything appears to be in order and i have klipper firmware flashed to my skr pro v1.1. It shows it connects to the printer but when i try to move one of the stepper motors it says 'printer not ready' klippy.log open up a ssh terminal and run lsusb, it should display the board. Check if /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-1f00 exist

[MrKekson]

I don't think issue tracking should use as a support tool, but see if ls -l /dev/serial/by-id/ give anything back to you, and enter the exact text from there. My board is working (except 1 klippy mental disorder) for 2-3 weeks now, so i don't think it's a mcu issue, more like something off with your config file or with your build config. If you ask this on klipper's facebook i can help you, but don't want to spam this issue.

[jcm11215]

here is what i get

pi@octopi:~ $ ls -l /dev/serial/by-id/ total 0 lrwxrwxrwx 1 root root 13 Oct 16 22:32 usb-Klipper_Klipper_firmware_12345-if00 -> ../../ttyACM0

Im gonna post on the klipper facebook page im a member now maybe u can help thx

[ghost]

What is the current status on the Bigtreetech SKR Pro? Are there many remaining problems? I think of getting the SKR Pro together with 4 TMC5160, but I wasn't able to figure out how many problems I will encounter when running it with klipper. Would you recommend this combination?

[sergiocipo]

I upgraded my Hevo with SKR Pro and tmc5160 some weeks ago there is no issue at the moment with this configuration fo me

[ghost]

I am using a Rasp Pi 3B+, SKR pro, TCM5160s and an Ender 5 platform with mostly stock parts. The SKR was a pain to wire properly

I have the same configuration, SKR Pro with TMC5160. How did you wire them?

[MrKekson]

What is the current status on the Bigtreetech SKR Pro? Are there many remaining problems? I think of getting the SKR Pro together with 4 TMC5160, but I wasn't able to figure out how many problems I will encounter when running it with klipper. Would you recommend this combination?

I've using it for a one and a half month. I've got some weir problem, where the G28 ends, before it's finish homing, so octo start to stream the commends, but every command met with a "Home axis first" message, but restarting the print usually solve this problem. Everything else id ok. Also, i see no benefit for 5160, since it's not a CNC, so you won't get any real load on your head, but 2130 on spi is working fine and mighty.

[ghost]

Does anybody have the sensorless homing feature working?

I successfully configured the SKR Pro with the BTT TMC5160 V1.2 and I can move steppers, change current, read TMC registers etc, so it seems to work well. However I can't get sensorless homing to work, no matter which value I set for driver_SGT. The chapter Stallguard2 in the TMC5160 manual gives the same information as on the TMC2130, so I started with that configuration.

However, according to this specification for the BTT TMC V1.2 https://www.biqu.equipment/products/bigtreetech-tmc5160-v1-0-driver-spi-mode-silent-high-precision-stepstick-stepper-motor-driver-with-heatsink-for-skr-v1-3-gen-v1-4-reprap the diag1 pin is just an unpopulated hole (on the top, second one from left). I hooked up my Oscilloscope, but I can't see any signal there, regardless of the driver_SGT value, I only see a little noise while the stepper is running.

Where is the physical port PB10 located, that the diag1 from the X-Axis is supposed to get connected to? I can't find that in any documentation.

[MrKekson]

there is a part in the 5160 config saying

    "diag0_error":              0x01 << 5,
    "diag0_otpw":               0x01 << 6,
    "diag0_stall":              0x01 << 7,
    "diag1_stall":              0x01 << 8,
    "diag1_index":              0x01 << 9,
    "diag1_onstate":            0x01 << 10,
    "diag1_steps_skipped":      0x01 << 11,
    "diag0_int_pushpull":       0x01 << 12,
    "diag1_poscomp_pushpull":   0x01 << 13,

now if i'm right, this two pin is configurable, so we (as in someone know about this part are about) can theoretically change the pins. But i have no clu what is happening here, maybe some bit flags?

if we can't change this, we can still poll the driver trough spi, for the diag status, and set or connect the proper, but that has to be implemented too