TMC2209 drivers do not work correctly via UART

Basic Information:

Printer Model: Flying Bear Ghost 5
MCU / Printerboard: MKS Robin Nano 1.3
klippy.log

klippy.log (3.9 MB)

Describe your issue:

Hello
After connecting the drivers via UART, the printed models became tilted along the X and Y axes (skipping steps). When the drivers are in manual mode - everything is fine.

The printer has no mechanical problems (the table is smooth and moves smoothly, the axes move smoothly, the belts are tight, there are no jams).The current to the motors in manual mode and in UART is set to the same.

I began to experiment with the parameter: step_pulse_duration
By default, the klipper sets this parameter for TMC2209 drivers connected via UART to 0.0000001. For drivers in manual mode: 0.000002
I set the configuration parameter to 0.000002 and got a good print.

Why does the klipper set this parameter by default so that the drivers do not work correctly? How to choose the right value for this parameter?

Hello @rusvas86 !

I have no issues with the Klipper given settings.
Have you thought about increasing the stepper current?

I increased the current from 0.8A to 1A - it did not help.

1 Like

All the trinamic stepper motor drivers are rated for 100ns step pulse duration. So, the Klipper code defaults to that. Using that timing allows for some useful step optimizations.

Unfortunately, a handful of boards have placed voltage “level shifters” on the step pulse pins that are not rated for 100ns. There’s no way for Klipper to know that and it would not make sense for Klipper to pessimize the vast majority of boards for a handful using poor wire routing. So, the default remains 100ns, and users with impacted boards will need to manually set a step pulse duration.

That said, I don’t know if the Robin Nano has that issue. It is also possible that your particular board (or stepper driver) has an issue on the x stepper step wire. I don’t recall seeing similar issue reports for the Robin Nano.

Cheers,
-Kevin

4 Likes

You could share the schematics of your board. The community can check, if “level shifters” are involved.

I took measurements with an oscilloscope on the step and dir pins.

With step_pulse_duration: 0.000002 I see pulses of constant duration. When the motor speed changes, the pulse frequency changes. Everything is good here!

With step_pulse_duration: 0.0000001, the pulse duration is variable, the frequency is also variable. The duration of the shortest pulse in the series is greater than 100 ns. After a series of pulses, the step pin is high. It seems to me that this is the reason that the next time the motor runs, there will be a microstep skip.

With step_pulse_duration: 0.0000002 the situation is the same as with 0.0000001. At 0.0000003 and above, the situation is similar to 0.000002.





MKS_Robin_Nano_V1.3_SCH.pdf (835.8 KB)

You do NOT have UART communications with the TMC2209s in your Flying Bear Ghost 5 printer.

When I look at the schematics that you posted (which are the same as what’s on the MKS Github page - MKS-Robin-Nano-V1.X/MKS Robin Nano V1.3_002 SCH.pdf at master · makerbase-mks/MKS-Robin-Nano-V1.X · GitHub) I don’t see any provision for a UART connection for a TMC2209 chip.

The stepper motor driver socket schematic is:

Which doesn’t have any UART connection - if it did, you would see something like (taken from the Robin Nano V3.1 schematic):
image

Note that in the V3 drive wiring there is the UART connection (as well as the “TMC” clocked serial) which isn’t present in the V1.3.

Doing a quick scan, I see that that the TMC2209s will work in the Robin Nano V1.3 but only in “Standalone Replacement” mode as shown in the TMC2209 datasheet (starting on page 2) here: https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC2209_Datasheet_V103.pdf

I just noticed that in the Flying Bear website, they have a page on installing TMC2209s that notes that you should buy the modules without the UART pins: Replace and Tune TMC2209 drivers | Flyingbear Ghost Wiki and they seem to indicate that reason to do the update is to get quieter printer operation.

I’ve spent this time noting this because it looks like you’re thinking that you are changing the TMC2209 max current in Klipper using the UART connection which isn’t the case. You will have to twiddle with the pots on the driver modules and check the VREF voltage levels with a DMM.

Where did you get the Klipper firmware for your printer? If you built it yourself, what parameters did you use? There’s a good chance that it was created for an STM32F MCU but with the wrong part number and the clock specification is wrong resulting it in not running at the correct speed or at a default speed, which I believe is 8MHz. I’m pointing this out because the actual pulse size for the 200ns specification is not as accurate as I would expect.

The MKS Robin Nano V1.3 uses the same PCB as the Robin Nano 1.2, just the MCU and some passive parts are changed. Looking around at various online comments about the Ghost 5 and controller problems as well as their own website, it seems like Flying Bear puts in whatever they can find and you may get different controllers and drivers.

To summarize.

  1. While you’re using the TMC2209s stepper motor drivers with your printer, your hardware does not have the capability of communicating with the driver chips using a UART; they are working as stand alone drivers.
  2. To change the maximum current driven by the stepper motor drivers you will have to access the pots on the stepper motor modules.
  3. You need to confirm the MCU on your controller board and verify that the Klipper firmware was built for it to ensure you are running the MCU at maximum speed.

The simplest (and least costly) solution to your issues will probably be to run with the 200ns STEP pulses as you are doing now.

TMC2209 are connected via uart using wires and pin PA1.

I have no problem with uart communication. Motor currents are set correctly via config.

My board has an STM32F407. The firmware is assembled for this MCU.


From the last image above it looks like you added the UART line manually. Can I ask how did you verify that it works correctly?

When I look at your Klipper.log, it looks like you’ve set up:

  • X as Port “3”
  • Y as Port “4”
  • Z as Port “5”
  • Extruder as Port “1”

Where the Port numbers are specified in the Robin Nano V1.3 schematic.

Which leaves Port 2 and you’ve used pin PA1 (“DIR2”) as the UART line and specifying different “uart_address” values for each of the four steppers.

The problem is, PA1 isn’t muxed to a UART TX pin. If I look at the STM32F407 datasheet (https://www.st.com/content/ccc/resource/technical/document/datasheet/ef/92/76/6d/bb/c2/4f/f7/DM00037051.pdf/files/DM00037051.pdf/jcr:content/translations/en.DM00037051.pdf) PA1 can be configured as a UART RX (or RTS and other functions) pin:

In the image above, I included the PA0 pin to show that it can be configured as a UART TX (and CTS/other functions) pin. When I look at “EN2” (PA3) and “STEP2” (PA6) in the datasheet, they can’t be configured to UART TX’s either.

So, how did you verify that you have UART communications with your TMC2209’s? You have the oscilloscope capability - could you post a picture of the UART communications from PA1 to verify that it is there and correct?

I don’t believe Klipper can bit-bang a UART signal - although I would ask @Sineos and @koconnor to verify.

Uart addresses in printer.cfg are configured like this: X - 0, Y - 1, Z - 2, E - 3

Klipper can use any mcu pins for uart. At least on the PA1 pin, uart works for many people from the Flying Bear Ghost 5 community. I also tried pin Bltouch PA8 - it works.

I set low current for the motors in the configuration and saw that the motors could not move normally. Then I set the normal current and the motors moved normally. So setting the current of the motors by UART works fine.

DUMP_TMC STEPPER= command gives out information on TMC2209, which means that the uart works fine.

The above is the expected behaviour. Klipper programs the Trinamic driver to use “step on both edges” - thus steps do not occur on “pulses”, but instead on each “edge”. This mechanism works on all normally wired control boards and is an important optimization.

I know some Mellow boards needed an explicit step_pulse_duration because the boards have a custom “level shifter” circuit that could not transition from high-to-low quickly if the line was left high for any significant duration. Otherwise, I’m not aware of any other boards having a systemic issue.

I don’t know why your particular board is losing steps. Perhaps there is some large amount of capacitance on the step wire for that driver.

Cheers,
-Kevin

EDIT: Just to be clear, Klipper programs the tmc driver into “step on both edges” mode if step_pulse_duration is 200ns or faster (with the default being 100ns). If Klipper is asked to use a step_pulse_duration greater than 200ns then it disables the “step on both edges” optimization.

1 Like

Hey Kevin,

Are all the UART operations in Klipper bit-banging or is there or can be a UART involved?

I thought I read somewhere that UART operations in Klipper had to use a pin that is muxed to a UART.

Also, you should double check that your uart addresses are communicating with the correct drives. Klipper will verify that it is in contact with a tmc driver, but it can’t know which tmc driver it is talking to. If there is a mix up in uart addressing it could cause havoc.

-Kevin

Klipper always uses bit-banging to communicate with the tmc driver. Klipper never uses mcu uart hardware blocks for this purpose. Frequently Asked Questions - Klipper documentation

-Kevin

1 Like

Thanx for the pointer and the information.

Thanks for the answer.
What problems could be using step_pulse_duration: 0.000002 ? Top speed limit?

@rusvas86, which Klipper version are you using. I had a look in the schematics you posted. There are no “level shifters” involved. But the schematics are a kind of funny. I have the impression the Chinese fellows didn’t include every connector.

If using a 2us step pulse duration, then the theoretical maximum number of steps per second for that one motor is 250K, but in practice you’ll be limited to around 100K steps/s. That may limit the maximum velocity for a particular motor. Should that limit be reached you would receive a “stepper too far in the past” error. If you have not received that error then it is unlikely to be an issue.

-Kevin

1 Like

Klipper v0.10.0-615

Maybe the mcu is working correctly, and the problems may be on TMC2209.