Klipper: 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?

[klipper-gitissuebot]

Hi @towe96,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[JustAnother1]

I clicked the link and found a link to the user manual. To support a board a schematic of the board is needed. The schematic is not in the user manual.

If someone finds a schematic then porting might happen, without a schematic it will not happen.

[semos2k]

Hi, this is the info ?

https://www.dropbox.com/s/s75h3oemwrmqt31/SKR%20PRO%20V1.1%20Manual.pdf?spm=a219c.12010108.1000023.1.377e60cbhMUbbq&dl=0

[JustAnother1]

No. That only specifies which components are located where.

For porting the schematics is needed that specifies which pin is connected to which component or connector pin. The firmware just sends out signals on certain pins. Typical signal might be a PWM on pin C4. And if that pin is connected (over a MOSFET) to the heater then the heater will heat up. The Firmware will also wait for End Stop signals on a certain pin. If that is not the pin that the end stop is connected to then the firmware will just wait forever.

[towe96]

Once they start shipping the board, I'm sure an appropriate pinout will be posted on the Github page:
https://github.com/bigtreetech

But do we really require the pinout of the board for the support of the MCU? It though that would only be required for configuring it to work right, and should be extractable from their fork of Marlin once they release that.

[JustAnother1]

The STM32 ARM Cortex-M Processors are already supported. Not the 407, but this specific board also not. New peripherals need to be implemented. So WIFI and the USB port will need new firmware. And that will probably be more effort than adopting one of the STM32 drivers to the 407.

With a closer look at the picture posted by @semos2k the Pins are stated in the connector diagrams. So the pinout could probably be read from that. But some surprises might be still waiting as the schematic can for example easily invert PWM signals.

Therefore it probably makes no sense to start the porting before one firmware developer (or an interested user) has such a board in his/her hands.

[KevinOConnor]

I know a few people have expressed interest in a port to the STM32F4 platform (which is different from the STM32F1). I don't know when/if it will be implemented, however.

-Kevin

[mboyer85]

@semos2k
Hi, please is it possible to pull request your config and explain the steps for flashing the skr mini.
Thanks a lot

[mboyer85]

@semos2k
I mean : Flashing via SD card (like smoothieboards) or USB (which bootloader is present)
Thanks

[semos2k]

@mboyer85
This is only for testing, first i changed definition for right version of stm32f103, change "b" for "6":

Comment SPI in this line

and this

When execute "make menuconfig" select "28Kib bootloader" this param has present in the github of oficcial support marlin 2 ong bigtreetech github
https://github.com/bigtreetech/BIGTREETECH-SKR-MINI-V1.1/tree/master/firmware

And copy the klipper.bin to sd card renamed to "firmware.bin".

Regards,

[mboyer85]

Thanks a lot

[Hywelmartin]

At least there is a GitHub for this card now... https://github.com/bigtreetech/BIGTREETECH-SKR-PRO-V1.1

[Oranginator]

Schematic has been released https://github.com/bigtreetech/BIGTREETECH-SKR-PRO-V1.1/blob/master/Schematic/SKR-PRO-V1.1%EF%BC%88SCH%EF%BC%89.pdf

SKR-PRO-V1.1（SCH）.pdf

[mrkrynmdsco]

Hi, do we have any documentation on how to do porting?

[Oranginator]

Hi, do we have any documentation on how to do porting?

Afaik the MCU should now be supported. Correct me If I'm wrong https://github.com/KevinOConnor/klipper/tree/master/lib/stm32f4/include shows that.

I guess now we just have to do the printer.cfg with the schematic above.

[KevinOConnor]

I have been working on STM32F4 support. I have been able to bring up the STM32F446 board using serial (that chip is similar to the STM32F407). USB is not yet supported.

There's some info on porting at: https://www.klipper3d.org/Code_Overview.html

-Kevin

[JustAnother1]

USB is a rather complex interface. Best option is to use an available USB stack. For example this one https://github.com/abcminiuser/lufa
The vendor supplied ones are in my experience not the best. I'm sorry that I don't have the time to step up and get this implemented. If someone else can invest the time I offer to mentor. I also have some USB test equipment available, so once something works I could do tests. I think for Klipper USB CDC is important.

[MrKekson]

Hey, got the board, built, and flashed the rom. But it's dead. Cant see the board not as emulated com, or usb device. The board is blinking with the new flash, and it is working with the factory marlin. But since i can't connect to it, can't even see errors. Any ide how should i start?

[JustAnother1]

The USB of the STM32 will not work,yet. That is expected. Kevin said that USB is not yet supported.

What serial configuration did you use? Can you share the configuration you used?

What Host are you using? RaspberryPi? Can you use the serial line on the board. The RaspberryPi has UART Pins that can be used. You can also use an USB to UART converter.

[MrKekson]

Ah so not even simulated serial trough usb right? But actual serial with pins. I can try to wire it up tomorrow, since it's a bit late here. Also, i'm not proficient in python, nor to experienced with implementing usb, but if you can can you put together a few sentence roadmap, so i can investigate if i have the time to implement it. Nothing major, just a few guidelines, or just point me to the right direction, and i'll see if i have the time. But i do think this board can be candidate for the next ramps, if it did not have any major hardware failure.

But i can't move forward until i connect it trough pins, since it might work, but without klippy i would not know. Also do you have any docs on the serial pins i should i use?

[JustAnother1]

Yes not even simulated serial.

You won't need python for the USB Part. You will need to program in C. The few sentence version is: You need to configure the USB Device peripheral. So writing the correct Value into the registers. ST has example projects for USB to serial using their chips. That would probably be a good start. Because you also need to implement the USB Protocol. Right after plugging the device the Host will ask for a device report. That is what enables the PC to automatically install the correct drivers. This report is just a bunch ob bytes that need to contain the correct information. Once the request comes in the data needs to be send out. There are further reports that the host can request. The easiest is probably to reuse what ST provides. All this happens on End Point 0.
The serial communication then happens over other end points. So the firmware needs to handle incoming data on one end point and send out the serial data on the other end point. The good news is that you can just ignore the whole "set Baudrate" stuff and just accept whatever the host does or sends. This sending and receiving of the serial data then needs to be connected to the Klipper firmware and done.

How do you program the board? SWD ?

The schematic suggests to use UART3 on Connector J48. On the CPU that is UART3 on PD8(TX) and PD9(RX) that are pins 77 and 78. That seems very reasonably.

Best of Luck and don't hesitate to ask if you run into issues.

[gaggi]

I've just received my SKR-PRO today and had some time to fiddle around with it.
I got Klipper FW running with a few changes in the current version (https://github.com/KevinOConnor/klipper/commit/43ab8e71138483c0b39c6b89e6a704680ff72e1b)

I created a pull request with the necessary changes https://github.com/KevinOConnor/klipper/pull/1872

The bootloader needs to be set to 32KiB and I'm testing it with USART3 as Serial Port which can be accessed easily on The Header labeled UART on the bottom right corner.

[ETE-Design]

gaggi - So you communicate direct via UART only - RPI UART -> SKR Pro UART? How high Baud can it be bumped up to? And pls. add your config, your pull request is added now...

[gaggi]

Yes, I'm using the preset baudrate of 250k bps without any problems.
I don't have a complete config right now, just playing around a bit.

This is basically what I am using at the moment...

# This file contains common pin mappings for the BIGTREETECH SKR
# MINI. To use this config, the firmware should be compiled for the
# STM32F407 with a "32KiB bootloader".

# See the example.cfg file for a description of available parameters.

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

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

[stepper_z]
step_pin: PE13
dir_pin: PC2
enable_pin: !PC0
step_distance: .0125
endstop_pin: PG8
position_endstop: 0.5
position_max: 200

[extruder]
step_pin: PE14
dir_pin: PA0
enable_pin: !PC3
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PB1 # Heat0
sensor_pin: PF3 # T0 Header
sensor_type: EPCOS 100K B57560G104F
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250

[extruder1]
step_pin: PD15
dir_pin: PE7
enable_pin: !PA3
heater_pin: PD14 # Heat1
sensor_pin: PF4 # T1 

[extruder2]
step_pin: PD13
dir_pin: PG9
enable_pin: !PF0
heater_pin: PB0 # Heat2
sensor_pin: PF5 # T2

[heater_bed]
heater_pin: PF6 # T3
sensor_type: ATC Semitec 104GT-2
sensor_pin: PF3
control: watermark
min_temp: 0
max_temp: 130

[fan]
pin: PC8

[fan1]
pin: PE5

[fan2]
pin: PE6

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

[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100

I had to make a small change to the source again because the thermistor pins weren't set as ADC's in the current code, you can find the changes on my fork https://github.com/gaggi/klipper/commit/32229355b217c96dff675f778af94a2bf26ad66b

I hope that I can find some time for further tests tomorrow including a complete test print.
If everything went well, I will create another pull requests.

[ETE-Design]

Gaggi - Would it be possible to bump up the Baud even higher? Like, what would the highest Baud possible be?

[JustAnother1]

The 407 can do the 960 something kbit/s. It probably can also do 10MBit/s. It depends a bit on the clock source. But with an 8MHz crystal and the correct PLL config that should be no issue for the 407. (Sorry it has been a while for me since I last used these rates on a 407) But the wiring starts to become interesting at such rates. Also the noise immunity goes down. The bits get shorter so shorter distortions can flip a bit.

But does Klipper really need Baud rates above 1Mbit?

[gaggi]

Ok, I'm stuck. The thermistor pins on the SKR Pro (PF3-PF6) are on ADC Port 3 and nothing I tried to change in the adc.c seems to get ADC Port 3 working instead of or together with ADC Port 1.

[JustAnother1]

I was on a short vacation, but as nobody else answers here it goes:

from what I see the adc.c file is really only meant to work with ADC1. A search and replace "ADC1" to "ADC3" might be a first step. But also the adc_pins array would need to be adopted. and then probably more changes. And then it would only work for that board and not for the others.

So better do a "#define ADC_used ADC3" and check if all the pin definitions are still OK. Some bits might to change too to enable ADC3 instead of ADC1. So this is pretty much a complete rewrite of the adc.c.

If you, or someone else wants to take on the task, then get the data sheets and send me an email if you get stuck. My email is in my profile. I don't have the board, or a similar to do the testing and I'm rather busy right now.

[KevinOConnor]

FYI, I've updated the stm32 code to support USB (commit aac51bdb). I also updated it for the additional ADC ports (commit 4ec6db7a).

My test board is a bit different (an stm32f446 eval), so there may be quirks with both of the above support. Feel free to test though.

-Kevin

[Gonzo4]

Hi, I'm stuck at flashing the mcu:

I think I'm using the USB serial here and not the "real" USB connection, or?

[Hywelmartin]

@Gonzo4 put the klipper.bin on the SD-card to flash it..

[Gonzo4]

@Hywelmartin thanks I think that worked. Executing ls /dev/serial/by-id/* now returns /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00.

But I still could not connect?! klippy.log output:

Starting serial connect
Unable to open port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00'

[KevinOConnor]

Has anyone had success with the latest Klipper on the SKR pro? If not, who has tried?

But I still could not connect?! klippy.log output:

Try a full micro-controller reset, verify the device is in /dev/, restart the klipper software, and then attach the Klipper log from the session.

-Kevin

[gaggi]

I've just flashed the most recent version (https://github.com/KevinOConnor/klipper/commit/c95209bf7aeab1fa8ea867d85645a2171a5db590) with USB communication and the board shows up as a serial device, but that's it.

The only output i get when using the console.py script is the following

==================== attempting to connect ====================
INFO:root:Starting serial connect
DEBUG:root:Starting stk500v2 leave programmer sequence
DEBUG:root:Got '' from stk500v2
ERROR:root:Timeout on serial connect
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/serialhdl.py", line 92, in connect
    identify_data = self._get_identify_data(connect_time + 5.)
  File "/home/pi/klipper/klippy/serialhdl.py", line 57, in _get_identify_data
    params = self.send_with_response(msg, 'identify_response')
  File "/home/pi/klipper/klippy/serialhdl.py", line 156, in send_with_response
    return src.get_response([cmd], self.default_cmd_queue)
  File "/home/pi/klipper/klippy/serialhdl.py", line 225, in get_response
    raise error("Timeout on wait for '%s' response" % (self.name,))
error: Timeout on wait for 'identify_response' response
DEBUG:root:Starting stk500v2 leave programmer sequence
DEBUG:root:Got '' from stk500v2
ERROR:root:Timeout on serial connect
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/serialhdl.py", line 92, in connect
    identify_data = self._get_identify_data(connect_time + 5.)
  File "/home/pi/klipper/klippy/serialhdl.py", line 57, in _get_identify_data
    params = self.send_with_response(msg, 'identify_response')
  File "/home/pi/klipper/klippy/serialhdl.py", line 156, in send_with_response
    return src.get_response([cmd], self.default_cmd_queue)
  File "/home/pi/klipper/klippy/serialhdl.py", line 225, in get_response
    raise error("Timeout on wait for '%s' response" % (self.name,))
error: Timeout on wait for 'identify_response' response
DEBUG:root:Starting stk500v2 leave programmer sequence
DEBUG:root:Got '' from stk500v2

Connection via UART is still working fine.

[KevinOConnor]

@gaggi - Ok, thanks. Does the updated ADC code work?

-Kevin

[Gonzo4]

... I think I have the same problem, the klippy.log always ends with "Starting serial connect"...

[MrKekson]

same as @gaggi, visible on serials, but can't connect

log is pretty much:

Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00' Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00' Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00' Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00' Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00' Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00' Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00' Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00' Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00' Unable to open port: [Errno 16] could not open port /dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00: [Errno 16] Device or resource busy: '/dev/serial/by-id/usb-Klipper_Klipper_firmware_4-if00'

[tiaanv]

Hi guys

I probably shouldn' be in this thread, because of my comments below. Please excuse my stupidity. I promise I googled and searched for hours on end.

I had a smoothieboard, and managed to get that working in minutes with config, I then jumped to buy the V1.1 PRO, without even considering klipper, as I naturally thought it was the same fundamentally as the SKR 1.3. Shame on me.

I struggled with numerous parts of this process, first of was on how to get the specific hash commit? I'm not even sure I've done it right, as I have various failed results. Let's assume I pulled the git correctly and merged to the right branch.

I then ran make menuconfig. I changed to the right board, and from an earlier version, I could see some options changed. Below are my settings.

I also tried Use USB for communication but when I did that I get an error on MAKE:
make: *** No rule to make target 'out/board/usb_cdc_ep.h', needed by 'out/src/generic/usb_cdc.o'. Stop.

I also at some stage with different variation of source got the following MAKE error:
make: *** No rule to make target 'out/board/usb_cdc_ep.h', needed by 'out/src/generic/usb_cdc.o'. Stop.

When I don't use USB comms the make runs successfully and I get the following compiled:
Version: v0.7.0-759-g4ec6db7-dirty-20190829_065625-octopi
another version I compiled:
Version: v0.7.0-795-gc95209b-20190829_071315-octopi

Not sure which of these are more correct

None of this instills confidence in my ability to assist here, I know :)

Putting the firmware on the device does NOT make a USB port of any sort show up (plugged into Windows as well to check).

I assume, that compiling it the way I did will result in it being in UART config. I don't think I'm going to mess around with the UART port, so I'll rather work on the USB bits.

I would love to assist with further debugging if you could assist in these first hurdles.

1. How to ensure I get the correct tree/commits from GIT
2. Settings for menuconfig.
3. Expectation of what I should end up with.

Thx

[Gonzo4]

for the update I think:

cd ~/klipper;
git fetch;
git pull;
sudo service klipper restart;

..after the fetch you can use git status or git log...

[tiaanv]

@Gonzo4 . The last (top entry) in my git log is

pi@octopi:~/klipper $ git log
commit c95209bf7aeab1fa8ea867d85645a2171a5db590
Author: Kevin O'Connor <[email protected]>
Date:   Wed Aug 28 13:45:01 2019 -0400

    atsam: ADC pins need to be in input mode with pullups disabled

    The ADC pins (on at least the sam3x8e) need to be configured in input
    mode with the internal pullups disabled in order to get accurate ADC
    readings.

    Reported by @bryanboettcher.

    Signed-off-by: Kevin O'Connor <[email protected]>

I think that's correct. But running make with USB enabled gives me this error:
make: *** No rule to make target 'out/board/usb_cdc_ep.h', needed by 'out/src/generic/usb_cdc.o'. Stop.
With Serial it compiles, but usb not working at all

[gaggi]

@tiaanv try it again with a "make clean" before the "make"

[tiaanv]

@tiaanv try it again with a "make clean" before the "make"

That did the trick. now have a serial port showing up.

Now I am stuck at the same place most seem to be. The serial port is not responsive. ironically, thats progress!

[tiaanv]

After messing around quite a bit. This is the info I can provide. Most likely like others more of the same, but perhaps it can help:

DMESG:
[ 217.590688] cdc_acm 1-1.5:1.0: failed to set dtr/rts

klippy.log:

Starting serial connect
Unhandled exception during connect
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/klippy.py", line 138, in _connect
    cb()
  File "/home/pi/klipper/klippy/mcu.py", line 639, in _connect
    self._serial.connect()
  File "/home/pi/klipper/klippy/serialhdl.py", line 85, in connect
    stk500v2_leave(self.ser, self.reactor)
  File "/home/pi/klipper/klippy/serialhdl.py", line 238, in stk500v2_leave
    ser.read(4096)
  File "/home/pi/klippy-env/local/lib/python2.7/site-packages/serial/serialposix.py", line 501, in read
    'device reports readiness to read but returned no data '
SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
Attempting MCU 'mcu' reset
Unhandled exception during post run
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/klippy.py", line 182, in run
    m.microcontroller_restart()
  File "/home/pi/klipper/klippy/mcu.py", line 786, in microcontroller_restart
    self._restart_arduino()
  File "/home/pi/klipper/klippy/mcu.py", line 754, in _restart_arduino
    serialhdl.arduino_reset(self._serialport, self._reactor)
  File "/home/pi/klipper/klippy/serialhdl.py", line 254, in arduino_reset
    ser.dtr = False
  File "/home/pi/klippy-env/local/lib/python2.7/site-packages/serial/serialutil.py", line 469, in dtr
    self._update_dtr_state()
  File "/home/pi/klippy-env/local/lib/python2.7/site-packages/serial/serialposix.py", line 636, in _update_dtr_state
    fcntl.ioctl(self.fd, TIOCMBIC, TIOCM_DTR_str)
IOError: [Errno 110] Connection timed out

OctoPrint:
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

[MrKekson]

@KevinOConnor i1m willing to give a temporal ssh access to you if it can help, or if you have any idea how to debug this i can try if my pi is not running the other 2 printers

[KevinOConnor]

As a simple test - what happens if you flash the board, remove the sd card, start up the klipper host software, wait 30 seconds or so, then press the skr's reset button (without altering the usb plug)? After running that test, attach the full klipper log file here.

-Kevin

[tiaanv]

As a simple test - what happens if you flash the board, remove the sd card, start up the klipper host software, wait 30 seconds or so, then press the skr's reset button (without altering the usb plug)? After running that test, attach the full klipper log file here.

-Kevin

1. Flash
2. Remove SD
3. sudo service klipper restart
4. Wait 30s hit board reset button.

Starting Klippy...
Args: ['/home/pi/klipper/klippy/klippy.py', '/home/pi/printer.cfg', '-l', '/tmp/klippy.log']
Git version: 'v0.7.0-795-gc95209b'
CPU: 4 core ARMv7 Processor rev 4 (v7l)
Python: '2.7.13 (default, Sep 26 2018, 18:42:22) \n[GCC 6.3.0 20170516]'
Start printer at Thu Aug 29 19:03:46 2019 (1567101826.5 20082.8)
===== Config file =====
[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 = P1.28
control_pin = P1.23
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 = 
    M140 S{BED_TEMP}
    G90
    SET_GCODE_OFFSET Z=0.0
    G28
    Z_TILT_ADJUST
    G1 Z5 F3000
    G1 Z0.15 F300
    M190 S{BED_TEMP}
    M109 S{EXTRUDER_TEMP}

[gcode_macro END_PRINT]
gcode = 
    M140 S0
    M104 S0
    M106 S0
    G91
    G1 X-2 Y-2 E-3 F300
    G1 Z10 F3000
    G90
    G1 X260 Y280 F6000
    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_lookahead_time = 0.010

[heater_bed]
heater_pin = PF6
sensor_type = EPCOS 100K B57560G104F
sensor_pin = PF4
control = pid
pid_kp = 94.9
pid_ki = 4.187
pid_kd = 538
min_temp = 0
max_temp = 250
pwm_cycle_time = 0.1

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

[fan]
pin = PPE5

[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

[static_digital_output leds]
pins = P1.18, P1.19, P1.20, P1.21, P4.28

[mcp4451 stepper_digipot1]
i2c_address = 44
scale = 2.25
wiper_0 = 1.0
wiper_1 = 1.0
wiper_2 = 1.0
wiper_3 = 1.0

[mcp4451 stepper_digipot2]
i2c_address = 45
scale = 2.25
wiper_0 = 1.0
=======================
Extruder max_extrude_ratio=0.266081
Starting serial connect
Unhandled exception during connect
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/klippy.py", line 138, in _connect
    cb()
  File "/home/pi/klipper/klippy/mcu.py", line 639, in _connect
    self._serial.connect()
  File "/home/pi/klipper/klippy/serialhdl.py", line 85, in connect
    stk500v2_leave(self.ser, self.reactor)
  File "/home/pi/klipper/klippy/serialhdl.py", line 241, in stk500v2_leave
    res = ser.read(4096)
  File "/home/pi/klippy-env/local/lib/python2.7/site-packages/serial/serialposix.py", line 501, in read
    'device reports readiness to read but returned no data '
SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

[tiaanv]

This may mean nothing, but out of desperation I plugged the board into my windows PC and messed around with PUTTY. I could not get putty to do anything it froze until I changed the flow control from XON/XOFF (the default) to DSR/DTR. I finally ended up with this:

 ?3▒@▒*~
     ?3▒@▒*~
            ?3▒@▒*~
                   ?3▒@▒*~
                          ?3▒J▒m$▒~
                                   ?3▒@▒*~
                                          ?3▒@▒*~
                                                 ?3▒@▒*~

this repeats this pattern. I understand that the underlying protocol is binary, so I was not expecting sensible data, but at least data is flowing?

[KevinOConnor]

Interesting. That shows that the 5 second stats message are being generated and successfully sent. A USB packet capture on the raspberry pi may help.

To setup for the packet capture, run:

sudo apt-get udpate
sudo apt-get install tcpdump
sudo modprobe usbmon

Then open two ssh terminal windows.

In one window start the capture, by running:

sudo service klipper stop
sudo tcpdump -i usbmon0 -w usblog.pcap

Then tap the reset button on the SKR.

Then in the second terminal window run:

sudo service klipper start

Then wait like 30 seconds, and hit cntr-c in the first window to end the capture. Zip the resulting usblog.pcap file and attach it here.

-Kevin

[tiaanv]

usblog.zip
Done.

[KevinOConnor]

Interesting. The packet dump indicates the usb is writing bulk packets okay, but not reading them. My stm32f446 test board doesn't exhibit that behaviour.

You could try the work-stm4usb-20190830 test branch to see if that improves things:

cd ~/klipper ; git fetch ; git checkout origin/work-stm4usb-20190830 ; make ; ... flash ...

-Kevin

[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 [e-mail] 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.

[CalielOfSeptem]

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.

[CalielOfSeptem]

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

[CalielOfSeptem]

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

[CalielOfSeptem]

@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?

[CalielOfSeptem]

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 [e-mail] 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

[CalielOfSeptem]

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.

[CalielOfSeptem]

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

[Spacemarine2018]

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

[Spacemarine2018]

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.

[Spacemarine2018]

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

[Nelanius]

Hi @Spacemarine2018,
I am having some issue getting my Skr pro with tmc5160s working.
Currently my steppers only move in one direction and my steppers are wired AABB.
Could you post your config so i could compare it to mine?

[Spacemarine2018]

Here you go @Nelanius
printer.cfg.txt
I don't have the sensorless homing working, I just connected the physical switches, so the config looks misleading in that section.

[Spacemarine2018]

Can anybody with a working TMC5160 V1.2 from BTT and an SKR Pro post the printer.cfg? I'm having the problem that I can write via SPI, but not read and I want to make sure that it's not a configuation error.

Also please check if you get meaningful values (not only 00000 or fffff) when doing DUMP_TMC STEPPER=stepper_x just to make sure you can actually read and not only write SPI.

[MrKekson]

Only for 2130, should be similar i guess, do you need it?

On Tue, 5 Nov 2019 at 13:41, Spacemarine2018 [e-mail]
wrote:

Can anybody with a working TMC5160 V1.2 from BTT and an SKR Pro post the
printer.cfg? I'm having the problem that I can write via SPI, but not read
and I want to make sure that it's not a configuation error.

Also please check if you get meaningful values (not only 00000 or fffff)
when doing DUMP_TMC STEPPER=stepper_x just to make sure you can actually
read and not only write SPI.

—
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=AAWUDIWKHUND7L6I6D7W7NDQSFSYXA5CNFSM4HYPLMZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDCWE6I#issuecomment-549806713,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAWUDIT2VCPXUWID3SM27HDQSFSYXANCNFSM4HYPLMZQ
.

--
Oli

[tiaanv]

@Spacemarine2018. Why not run them in UART mode?
I ran my 2209s in UART mode. I'm pretty sure the technical bits on the 5160s are good ng to be the same. Only. Small thing that's incorrect on the specs for config. TX and RX are on the same pin... So in klipper you need to delete or comment out the TX pin line in the driver. Onfig sections

[Spacemarine2018]

@MrKekson does it differ from the config example here? https://github.com/KevinOConnor/klipper/blob/master/config/generic-bigtreetech-skr-pro.cfg If it's basically the same, I don't need it, but thanks!

@tiaanv interesting idea, I never thought of using UART because everyone seems to use SPI. Any benefit/drawback since the TMC5160 supports both?

[MrKekson]

You are right, this file was not available when i've configured my machine,
but that should be ok too!

On Tue, 5 Nov 2019 at 15:41, Spacemarine2018 [e-mail]
wrote:

@MrKekson https://github.com/MrKekson does it differ from the config
example here?
https://github.com/KevinOConnor/klipper/blob/master/config/generic-bigtreetech-skr-pro.cfg
If it's basically the same, I don't need it, but thanks!

@tiaanv https://github.com/tiaanv interesting idea, I never thought of
using UART because everyone seems to use SPI. Any benefit/drawback since
the TMC5160 supports both?

—
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=AAWUDIRCZ6QLBFF2RJFP6H3QSGAYRA5CNFSM4HYPLMZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDC5RZI#issuecomment-549837029,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAWUDISE67MHVZ7TBYXYV2TQSGAYRANCNFSM4HYPLMZQ
.

--
Oli

[KevinOConnor]

I'm going to close this issue as I think the original issue (stm32f4 support) is now complete.

-Kevin