Performance issues with Atmega1284p

General Discussion
1

Basic Information:

Printer Model: custom
MCU / Printerboard: Sanguinololu with Atmega1284p and TMC 2209 stepper drivers
Host / SBC
klippy.log
klippy.log (116.6 KB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

…

I connected Atmega1284p to klipper on Rasberry Pi 3B+. After setting everything up according to documentation, and performing final checks, everything looks working. I can use manual controls to move and home axis, they are moving more or less correct distance at correct speed. All heaters are working and achieving correct temperatures.
I have no issues until I try to actually print a gcode.

The print starts fine, but after some time Y axis is getting stuck in moving in one direction.
So when I’m trying to print diagonal lines, X axis is moving correctly from left to right, but Y axis just goes forward (while it should be moving forward and backward).
I managed to get 3 correct layers by going 10mm/s, but even with that slow speed I got some errors later. They were much smaller and after them printer again started working correctly.

I think it’s performance/communication issue on MCU or Klipper side, because I got better results when I limited microsteps to 8 and slowed print down.
I know Angela 1284p is slowest what klipper can work with, but it is supported and I found people that were using it. Also, Sanguinololu was working fine for me, and I wasn’t expecting performance loss when switching to Klipper.

Thanks for any help, I banging my head at wall for few days now, and I can’t even think of what I can change. There’s not that much options during installation and configuration

2

The klippy.log would not indicate that the ATmega is overwhelmed by the requested step rates or bandwidth and generally, Klipper is able to obtain way higher step rates on this low-end 8bit hardware than Marlin.
Actually, this was one of the driving development factors for Klipper that nowadays switched to high-speed printing.

This seems a bit strange reasoning. Of course you can use it but also of course, you will never reach the step rates of a high-end STM or similar chip.
Even Klipper can’t do any magic and make a 8bit board support a 20k accel printer at 300 mm/s and above.
See Benchmarks - Klipper documentation for an idea of the proportions.

This description does not sound like a step rate issue. Does this board support UART controlled TMCs or are they stand-alone?

The provided log does not contain any Klipper error messages. Still the setting:

[printer]
...
max_velocity = 500
max_accel = 5000
...

seems quite optimistic for such a board.

3

I know, my reasoning is, that klipper shouldn’t work slower than sanguinolu. Or at least that’s what I thought.

Yeah, I’m changing that manually to 100 for now. I’m aiming to 100mm/s and 3000 mm/s2. Microstepping 64 would be nice.

Stand-alone.

So maybe it’s hardware issue, I tried switching cables and stepsticks, and issue is somewhere before stepstick

4

klippy (1).log (3.3 MB)
I got some errors when i tried to increase step pulse duration, but also i got them from time to time in the past.
Maybe in this log will be something more.

5

See Rescheduled timer in the past
This is indeed an error caused by too high step rates.

Lets assume

  • full_steps_per_rotation: 200
  • microsteps: 64
  • rotation_distance: 32
  • velocity: 100

So, if I did not botch the math:

steps\_per\_mm = \frac{full\_steps\_per\_rotation * microsteps}{rotation\_distance} = \frac{200 * 64}{32}=400

and

steps\_per\_sec = steps\_per\_mm * velocity = 400 * 100 = 40000

with a 20 MHz AVR having a total step rate of 123000 steps with 3 steppers.

So with 40K steps per stepper (X, Y) you should have a bit of leeway. Note, however, that these are theoretical and synthetic maxima, which do not take into account the fact that your printer has a few more tasks than just feeding the steppers.

Also, I have no experience with these 8-bit boards under Klipper, so it is hard for me to say what a realistic expectation is.

6

Yeah, and I got this error while running it at 8 microsteps and 20 mm/s, so I should be way below, even if using 16Mhz AVR.
I will try to wire tmc2209 via UART, and if that will not work, I will replace the board. It’s irritating, but i have no clue what to do next.

Thanks for the help :slight_smile:

7

FYI, if one increases the step_pulse_duration it naturally limits the total number of steps possible. For example, if the step_pulse_duration is set to 8us then that means each step must take a minimum of 16us, which means the maximum possible number of steps per second would be 62500 (1.0 / 0.000016). Note however, the software can’t reach these maximums in practice, so one should half that rate again.

So, to summarize, if a particular driver needs a higher step_pulse_duration then it necessarily imposes a significantly lower step rate on that motor.

-Kevin

1 Like