Mainsail/klipper is stalling/pausing during printing

General Discussion
1

I am new with my voron, finished the build last week and doing some tests with it.
But running in an issue, i don’t know what causes the problem

Slice:
Cura 5.4

Hardware:

  • BTT octopus F429
  • BTT canbus SB2209
  • Thinclient with ubuntu, but later a raspberry pi 3B+

Software:

  • Klipper V0.12.0-8g187cc2f1
  • Mainsail 2.8.0
  • Mainsail config V1.1.0-1-g76a99999
  • Moonraker 0.8.0-202-gdddd968f

The problem is the same as in this video.
This is not my printer, but found a video which shows the same issue

Because i run a thin clien on ubuntu and this is not the standard solution, i changed this to a raspberry pi 3B+. Followed the instruction from kiauh how to setup the pi and install the software. But no difference, same problem.

Googled and found that i am not alone with this problem. But almost in all those threads, the solution is not described. Found some information that minimum layer time could be the problem. Set that on 0, but still the same problem. The pi could give “under voltage”, never seen that notification.

I hope somebody has an idea how to solve this, or what is causing the problem?

2

Just a curious question. Why did you delete your attached klippy.log?

In that log the entry “Pausing toolhead to calculate extruder phase offset” is conspicuous.

3

klippy.log (1.2 MB)

Sorry, i noticed the video URL didn’t worked.
I modified the post, but didn’t noticed that i removed the klippy.log

At the moment the printer is running again, on the pi 3B+.
But now i used the superslicer as my slicer tool. The first few layers i watched and it looks like the stalling/pause moments are gone.

This is the first time i use superslicer. I always used cura with my previous printers.
The settings i used in superslicer are not perfect, but first i have to get rid of those stalling/pausing moments. When superslicer is the way to go, then i can search how to get familair with superslicer

4

The first superslicer test looks promising. The pausing is gone. But slicer settings are way off.

Most i can solve. Only on the corners, i looks like it is spitting out to much material. The corners has a bulb. Made a change to the jerk settings, tomorrow more testing

5

No prob. I don’t think it’s a slicer problem. Just take “Pausing toolhead to calculate extruder phase offset” and do a search here. It might lead you to Sineos in the end and other conclusions.

6

I pulling my hair out of my head, what is going on with the voron.

I searched on “Pausing toolhead to calculate extruder phase”, but there are only a very few hits. Unfortunally nothing that looks usefull.

I don’t get it what is going wrong. I have a sapphire pro with klipper and that one is running fine without issues. The voron is 4 times as expensive and the quality is very bad compared to the sapphire. just don’t get it, it is making me crazy.

7 
[printer]
kinematics = corexy
max_velocity = 30
max_accel = 300
max_z_velocity = 15
max_z_accel = 35
square_corner_velocity = 1.0

These values are not exactly looking correct. Try something along the lines of:

[printer]
kinematics: corexy
max_velocity: 300  
max_accel: 3000            
max_z_velocity: 15
max_z_accel: 350
square_corner_velocity: 5.0
8

I don’t know if those setting have solved the issue.
Just uploaded the same sliced code, but the printer is now that quick, that it is not easy to say if it still stops or not. Have to lower the speed in the slicer to see what it does.

Overall the printing quality went up.
I have bulbs on every layer, but looks like retraction that needs fine-tuning.

9

Well, all I can say that your previous settings were dead wrong and of course caused stopping issues.

10

Good that your main problem now appears to be solved.
I have also had minor inexplicable problems on my Voron. I too noticed that the RasPi was complaining about under voltage. Basically it under-clocks until it gets full volts again, in an attempt at self protection.
If your Pi is driven from the 5V supplied by the MCU, I would suggest buying a buck convertor to drop the PSU volts down to the 5v required. Mine cost £4.49 including postage, has screw terminals and plugs for in & out and accepts any input from 12 to 24V and is worth every penny. Make sure you get one capable of outputting 3A or more - you never know when you will get round to driving extra leds etc from the GPIO header. Prints are now much better quality.

11

Thanks for both replies.
I will work on with small steps to improve the quality.

I use an original pi supply. There are no under voltage notifications. Yes, have to plugin 2 wall plugs. But they idea js to switch back to the thinclient when everything works and see what happens. Still thanks for thinking with us.

12

The Pi’s power supply will never affect print quality. It will affect system stability and prevent strange Klipper shutdowns.
These DC converters are often of distressing quality, have high noise and their power ratings are wishful thinking.

Stick to it.

13

@Sineos hopefully no offence, but I beg to differ. Many DC buck convertors may well be of distressing quality, but so too are the onboard 5V supplies on some mcu boards. As long as noise produced by a standalone convertor is no more than the noise produced by an underrated on-board convertor incapable of supplying sufficient current, the standalone will produce a better print. Almost by definition, if the onboard convertor can’t supply enough current, the smoothing capacitors will allow more ripple on the output.

Personally I find the standalone convertor a better solution than an external wall-wart only providing power to the host and having to then switch 2 supplies on/off in the right sequence.

It is a shame that it is so difficult to find a replacement 200W+ PSU capable of supplying 200W at 24V with a 15-25W 5V secondary output, which would be the ideal solution.

Before changing to a standalone convertor, bottom and top surfaces on some prints (depending on size and shape) were producing surface ripples/waves. Installing the standalone convertor (thus removing underclocking warnings) has fixed this.

I am unsure of the actual mechanisms involved but I surmise that if the MCU/MCU UMB supplied with my Voron kit is not capable of supplying enough power to keep the host running at full clock rate, so too is the microcontroller but it has no means of issuing a warning. I’m guessing that this possibly introduces differential delays in microstepping between the A & B steppers thus making the 45° wave pattern I was seeing.

[edit] Forgot to mention I also haven’t suffered a comms loss resulting in the need to [Restart Firmware] since installing my standalone convertor. This may be co-incidental because I only made the change a week ago and I am still setting everything up.

14

This is not possible. Klipper makes sure step timings are accurate, and it will shut down if the MCU is experiencing a problem.

15

I did say I was only surmising. All I know is that I haven’t seen the waves on top/bottom surfaces since installing a standalone buck convertor to prevent under-voltage warnings and comms failures.
@jakep_82 Are you saying that my comms failures were because the mcu was shutting down because it had a problem with undervoltage and thats why I had to use a standalone convertor?

16

I have no idea if that was your problem, but power supply issues are one of the causes of MCU disconnects.

https://www.klipper3d.org/FAQ.html#i-keep-getting-random-lost-communication-with-mcu-errors

17

Absolutely with @jakep_82 here:

  • Your steppers are supplied by 24V from the main PSU
  • All voltages on the MCU board are generated from the 24V main PSU
  • The power supply of the board and all board electronics are completely independent of the power supply of the RPi
  • The connection between MCU and RPi is digital, so not affected by unclean supply voltage unless it is so unclean that the high / low signal is destroyed, which then would result in a loss of connection
  • Undervoltage warnings of the RPi will lead to CPU throttling, which in turn will lead to the dreaded Timer too close or Timeout with MCU / Lost communication with MCU
18

Again I beg to differ.

The power supply of the board and all board electronics are completely independent of the power supply of the RPi

This is not the case as explained below.

On the picobilical, 24V goes to the board via P10 where U6 (TPS5450DDAR) drops this to 5V. This passes thru F2 to P9 (labelled Pi power). This SAME 5V also passes to U3 (AMS1117-3.3V) which drops this to 3.3V for the RP2040 micirocontroller. If U6 cannot supply enough volts to drive the host, then it is also likely to drop below the minimum headroom (4.3V) for U3. Since the low volt warning is not emitted by the RasPi until it drops below 4.5V, that only leaves 0.2V extra drop before U3 also fails to regulate.

A similar power flow occurs on the BTT-SKR-pico except that it is possible to supply the 5V to the U10 (AMS1117-3.3V) from the USB port via a jumper labelled USB_PWR_Sel (SW_USB) next to the USB-C socket if you are programming the SKR away from a 24V suppply. There is a warning not to have this jumper in place when the board is in normal use. Again, if you are supplying the host from the 5pin host plug (5V & Uart), ALL 5V power is coming from U9 (TPS5450) .

Both of these onboard sources of 5v only have a 330µF smoothing cap. My standalone buck convertor has 470µF as well as HF noise reduction circuitry. Compared to the SKR & UMB 5V supplies it is probably overkill but as I said earlier it cured my previous problems.
[edit] just noticed there is an additional 1000µF next to P9 (Pi power) on the picobilical. This obviously helps against ripple better than my standalone convertor, but if the onboard TPS5450 can’t supply enough power, no amount of smoothing is is going to help.

19

Well, you are of course entitled to believe whatever you want.

With or without the Picobilical the steppers and stepper drivers are supplied by the 24V main supply.

The SBC is supplied by whatever and this whatever needs to supply enough power for the SBC to do its job.
As long as the SBC is properly supplied, no Klipper errors should pop up, e.g. Timer too close etc.
The “whatever” supply of the SBC will not affect print quality, as only digital data is exchanged between SBC and printer board.

20

It is not a matter of believing what I want. I totally agree with all your statements (and those of Jake) except

The power supply of the board and all board electronics are completely independent of the power supply of the RPi

I was just pointing out that the schematics of both boards clearly show that the microcontroller on each mcu is supplied by a 24V–>5V–>3.3V which is the same 5V as supplied to the host when kits are built to the wiring standard supplied with said kit. Thus it is clearly not independent. This is not a belief, it is a fact.

ie. If (as appears to be quite common) users have a problem with their printer, and they are supplying their host RasPi with power from any mcu, then the solution could well be:

  1. a separate wallwart PSU as used by @hoeby, or
  2. a standalone convertor supplied by the main 24V PSU to drop to 5V rather stressing the mcu’s supply.