Printers stop During long prints/ Loses connection

General Discussion
1

logs-20231025-164106.zip (5.6 MB)

Basic Information:
Printer Model: Modified JGMaker A5S
MCU / Printerboard: Bigtreetech SKR1.4 turbo with EZ TMC2209 Steppers

Running 2 JGMaker A5S’s with SKR1.4 turbo boards on a single laptop running linux. Printers work great except while printing longer prints. roughly around the 50% mark they lose connection to the MCU. Log is flooded with the same bytes retransmit message.

Things I’ve tried already, new/ different usb, running one printer at a time, changing baud rates, inspecting all cables.

I don’t believe it to be hardware related since its both printers stopping at the same time. I suspect its something to do with the linux but I just cant figure out what.
…

2

Hello @KillMek !

On the same model gcode?

3

Good morning,

Two different models, just both take around 36 hours to print. One printer is setup with Bowden the other is direct drive so even retraction, pressure advance and flow rates are all different.

4

Your error is:

Timeout with MCU 'mcu' (eventtime=61369.534085)
Transition to shutdown state: Lost communication with MCU 'mcu'

See Timeout with MCU / Lost communication with MCU for more details. Unfortunately this kind of error is hard to come by.

What is striking:

max_accel: 700.000000
max_accel_to_decel: 350.000000
square_corner_velocity: 10.000000
toolhead: max_velocity: 2000.000000
max_accel: 700.000000
max_accel_to_decel: 350.000000
square_corner_velocity: 5.000000
toolhead: max_velocity: 2000.000000
max_accel: 1000.000000
max_accel_to_decel: 500.000000
square_corner_velocity: 5.000000
toolhead: max_velocity: 2000.000000
max_accel: 1000.000000
max_accel_to_decel: 500.000000
square_corner_velocity: 10.000000
toolhead: max_velocity: 2000.000000
max_accel: 700.000000
max_accel_to_decel: 350.000000
square_corner_velocity: 10.000000
toolhead: max_velocity: 2000.000000
max_accel: 700.000000
max_accel_to_decel: 350.000000
square_corner_velocity: 5.000000

Your log shows an insane amount of seemingly unnecessary changes like above (multiple times a second). At least I could imagine that this is a contributor

2 Likes
5

A post was split to a new topic: Multiple Klipper instances

6

I see, I guess Ive never seen what a good Klippy log should look like. any ideas on how to keep the printer from changing the Maxs constantly? I use Orca slicer usually. I wonder if my maxes in the slicer are conflicting with the klipper set maxes. When I get home Ill make sure they match. Any other ideas on what I should change?

Also yes I believe that post was the first one I used for trouble shooting with no luck.

one other Idea I have is that Im running linux mint, perhaps if all else fails I’ll reconfigure the laptop with a different Linux OS

7

I’m not too familiar with Orca and my initial attempts left a mixed feeling. But I would also guess that the values do not really match to your printer as it hardly survives a velocity of 2000 mm/s and I surely would not recommend to up square_corner_velocity to 10 on such a bed slinger.

I’d try, e.g. Cura and see if the error persists. If not then somehow the slicer is to blame.

Since you are running multiple instances on a quite beefy machine, you do not use virtual machines, right?

8

Definitely no virtual machine. Laptop is running Linux as its only Operating System.
I think the max square velocity is set to 5 in my slicer, maybe I forgot to set the printer.cfg back after I was done experimenting.

Ill make the changes and report back how it is. Thanks for all the help!

9

@Sineos , Sorry About the late response, one of my Printers had the Heated bed die in the middle of testing. I am happy to report that fixing the constant acceleration changes seems to be the fix. In Orca slicer there are 2 different sections to select acceleration speeds and Maxes, the printer kept changing during infill or outer walls which seems to have sent way to many commands causing what I can only assume is a memory dump problem in Linux where it just ceased up when it didn’t know what to do.

To fix it I set all accelerations to the same numbers and let the print speeds be the only determining factor for speeds

I was able to send through 2 Two day prints that were successful with no problems on both printers simultaneously

10

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.