towe96 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Hi, this is the info ?

Screenshot from 2019-06-16 11-48-23

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

JustAnother1 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

mboyer85 commented 5 years ago

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

semos2k commented 5 years ago

@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 commented 5 years ago

Thanks a lot

Hywelmartin commented 5 years ago

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

Oranginator commented 4 years ago

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

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

mrkrynmdsco commented 4 years ago

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

Oranginator commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

JustAnother1 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Hi, I'm stuck at flashing the mcu:

grafik

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

Hywelmartin commented 4 years ago

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

Gonzo4 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

-Kevin

Gonzo4 commented 4 years ago

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

MrKekson commented 4 years ago

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 commented 4 years ago

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.

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

Thx

Gonzo4 commented 4 years ago

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 commented 4 years ago

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

pi@octopi:~/klipper $ git log
commit c95209bf7aeab1fa8ea867d85645a2171a5db590
Author: Kevin O'Connor <kevin@koconnor.net>
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 <kevin@koconnor.net>

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 commented 4 years ago

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

tiaanv commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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
Flash

Remove SD

sudo service klipper restart
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 commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

usblog.zip Done.

KevinOConnor commented 4 years ago

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

Klipper3d / klipper

STM32F407 support? #1733

[mcp4451 stepper_digipot2] i2c_address = 45 scale = 2.25 wiper_0 = 1.0