RPi mcu and external stepper driver tmc2209 uart issues

General Discussion
1

Basic Information:

Printer Model: Creality Ender 3 v3 SE
MCU / Printerboard: Default Creality Mainboard v4.2.7
Host / SBC Raspberry Pi 4B
klippy.log (62.6 KB)

Describe your issue:

I have gone through the documented steps to enable UART on the Pi and have managed to test it successfully from command line test scripts provided at GitHub - Chr157i4n/TMC2209_Raspberry_Pi: this is a Python library to drive a stepper motor with a Trinamic TMC2209 stepper driver and a Raspberry Pi. My setup includes 2 stepper motors (Creality 42-40) and 2 stepper drivers (BigTreeTech tmc2209). What I want to do is have Klipper control these steppers through the rpi mcu using the GPIO pins and including support for UART to allow for sensorless homing.

The short description of this effort is to enable a color-changing system with a 3D printed version of the 3D Chameleon. One stepper switches the colors and the other pushes the filament to and from the extruder.

Here is what I’ve configured so far:

[mcu rpi]
serial: /tmp/klipper_host_mcu

[tmc2209 manual_stepper stepper_selector]
uart_pin: rpi:gpio15
tx_pin: rpi:gpio14 # tested both with and without this line
stealthchop_threshold: 9999
run_current: 0.800
# hold_current: 0.500
sense_resistor: 0.110
diag_pin: ^rpi:gpio6
driver_SGTHRS: 255
interpolate: True

[manual_stepper stepper_selector]
step_pin: rpi:gpio16
dir_pin: !rpi:gpio20
enable_pin: !rpi:gpio21
endstop_pin: tmc2209_stepper_selector:virtual_endstop
microsteps: 16
full_steps_per_rotation: 200
rotation_distance: 40

After racking my brain on this for several hours, I found what seems to happen is klipper takes over the UART pins 14 and 15 and turns them into INPUT/OUTPUT pins. I see this from raspi-gpio.

Immediately upon reboot:

GPIO 14: level=1 fsel=4 alt=0 func=TXD0 pull=NONE
GPIO 15: level=1 fsel=4 alt=0 func=RXD0 pull=UP

After enabling the above block in my printer.cfg:

GPIO 14: level=0 fsel=0 func=INPUT pull=NONE
GPIO 15: level=0 fsel=0 func=INPUT pull=UP

I also observed that the above-mentioned command line scripts could no longer read the UART pins as well.

Running a DUMP_TMC command on this stepper, it can’t read the UART registers, I assume because klipper disabled the uart configuration on these pins:


12:44 PM
Unable to read tmc uart 'stepper_selector' register GCONF
12:44 PM
========== Queried registers ==========
12:44 PM
SGTHRS:     000000ff sgthrs=255
12:44 PM
TPOWERDOWN: 00000014 tpowerdown=20
12:44 PM
COOLCONF:   00000000
12:44 PM
TCOOLTHRS:  00000000
12:44 PM
TPWMTHRS:   00000001 tpwmthrs=1
12:44 PM
IHOLD_IRUN: 00081919 ihold=25 irun=25 iholddelay=8
12:44 PM
SLAVECONF:  00000200 senddelay=2
12:44 PM
========== Write-only registers ==========
12:44 PM
DUMP_TMC stepper=stepper_selector

Am I just way off in my configuration? I assume they need to be configured as manual steppers so they’re not tied to the printer kinematics. I’m able to move both steppers through klipper if I don’t use the tmc2209 section, but without it, I can’t leverage the endstop information from UART.

Thanks for any help you can provide!

2

Here is a picture of the setup:

IMG_7869
IMG_78691920Ă—1440 225 KB

3

The PiHat that I’m using is one that I custom designed using the information on Chr157i4n’s GitHub. Here is the schematic for that board:

Cursor_and_JLCEDA_Pro_2_1_64_d1969c9c_217bcf_-Half_Offline_Mode___Licensed_to-webguyatwork___Chameleon_PiHat-__Users_webguyatwork_Documents_EasyEDA-Pro_projects
Cursor_and_JLCEDA_Pro_2_1_64_d1969c9c_217bcf_-Half_Offline_Mode___Licensed_to-webguyatwork___Chameleon_PiHat-__Users_webguyatwork_Documents_EasyEDA-Pro_projects1920Ă—1691 242 KB

4

The short answer is that you can’t control stepper drivers directly from an Raspberry Pi.

Along with that, I think you should have spent some time with the TMC datasheets before assuming that the UART of a Raspberry Pi (or equivalent) can be used with the TMC driver. The 64bit serial packet used by TMC is not compatible with the (8bit) NRZ serial of the Raspberry Pi.

I just looked at Chr157i4n’s GitHub page and I don’t see any kind of information there (TMC or otherwise).

If you’re looking at having a small stepper controller board that is separate from the main controller board, you’re going to have to have an MCU on it (for this, you would probably want to go with an AtMega 2560 that you will load with the Klipper Firmware) and communicate with it via USB, serial or CAN.

5

Ok, it’s literally right there in the description of his GitHub: this is a Python library to drive a stepper motor with a Trinamic TMC2209 stepper driver and a Raspberry Pi.

There are actually lots of videos and tutorials out there that address controlling stepper motors and their drivers from a Raspberry Pi, including the TMC2209. None of them seem to address bridging that setup into Klipper, however, using the Pi as a secondary MCU, which has been flashed with the Klipper firmware per the instructions: RPi microcontroller - Klipper documentation

I’m not questioning whether the Pi can drive the steppers because I’ve got that working (with the UART connections). I’m questioning why Klipper is switching the UART pin configurations the way it does.

6

Apologies, the first line should have been:

The short answer is that you can’t control stepper drivers directly from an Raspberry Pi RUNNING KLIPPER.

You’re not flashing the secondary Raspberry Pi with Klipper “Firmware”, you’re adding an app to the system that allows some Klipper MCU capabilities to a secondary Raspberry Pi which connects to the primary host.

These capabilities are (listed in the page you reference):

  • SPI
  • I2C
  • GPIO
  • PWM

That’s it. Stepper motors require quite precise timing for proper operation in a 3D printer system and it has been determined that a Raspberry Pi (and similar devices) running a *nix OS cannot control them to the level of precision required.

I suggest that you look at how the Klipper host device communicates with MCUs to schedule the movement of steppers (as well as communicate with them).

Sorry.

7

Thanks for taking the time to help me think through this problem. I think I understand now why it won’t work and was hoping to find a way to work around it, like having Klipper run a Python script of some kind to trigger the GPIO through the OS. Then again, I get what you’re saying about the latency in response times.

So my solution was to purchase the BTT Octopus v1.1 board. It arrives tomorrow. I’m confident that I’ll be able to accomplish my goal using the extra steppers that this board will have on it.

1 Like
8

Can I ask why the Octopus?

If you’re looking at controlling just two steppers, isn’t that a bit of overkill?

9

Oh, for sure it’s overkill for what I was hoping to keep on a tight budget. But it leaves room for future expansion too if I think of something else to do with steppers.

1 Like