Stalls on RAMPS

On one of my last prints, I found that the print head froze/paused mid-wall, leaving a series of tiny blobs throughout the print, but only on one side:

This was sliced with Cura 5, and I don’t have any weird speeds (set to 60 overall, 90 for travel, walls are at 40 external), and I’ve been monitoring CPU load on the Pi (3B+) and nothing is above 15% (OctoPrint is constantly active, but klippy.py barely registers).

Anyone experienced this? I’m using an ancient Prusa clone with a RAMPS board, but this hadn’t happened yet and I’ve done quite a few prints.

Also, I’m having really strange extrusion artifacts (I don’t have pressure advance dialed in yet). Can’t post the second picture since I’m new, but will try in a reply.

Here you go, this is the layer seam as far as I can tell. Again, no weird speeds.

image

In the meantime I’ve been looking at the logs and found that print_stall keeps getting incremented:

Stats 15660.5: gcodein=7805357 mcu: mcu_awake=0.074 mcu_task_avg=0.000256 mcu_task_stddev=0.000242 bytes_write=13420436 bytes_read=2167560 bytes_retransmit=552 bytes_invalid=0 send_seq=255273 receive_seq=255273 retransmit_seq=158926 srtt=0.010 rttvar=0.005 rto=0.030 ready_bytes=56 stalled_bytes=0 freq=15998180 sysload=0.25 cputime=513.702 memavail=662284 print_time=15644.979 buffer_time=2.497 print_stall=318 extruder: target=210 temp=209.0 pwm=0.654
...
Stats 15665.5: gcodein=7809044 mcu: mcu_awake=0.021 mcu_task_avg=0.000175 mcu_task_stddev=0.000187 bytes_write=13422593 bytes_read=2168098 bytes_retransmit=552 bytes_invalid=0 send_seq=255319 receive_seq=255319 retransmit_seq=158926 srtt=0.010 rttvar=0.005 rto=0.029 ready_bytes=55 stalled_bytes=0 freq=15998178 sysload=0.23 cputime=513.875 memavail=662376 print_time=15648.644 buffer_time=1.156 print_stall=319 extruder: target=210 temp=209.3 pwm=0.704

Anyone got any useful tips regarding this? I’m assuming (from looking at the code) that the stalls are happening because there are many queued commands (I’m using tree supports in Cura, which add to path complexity somewhat), so I should cut down on speed below “normal” - I’ve tried combing the docs, this forum and GitHub issues, but I can’t find an explanation/troubleshooting guide that would help.

Adding a load graph of one of these prints for reference:

Are you using Octoprint?

Yes, I mentioned that in the original post - but I have timelapses disabled. Also OctoKlipper, etc.

Then you’ll either need to use virtual SD, or increase the minimum line segment length in your slicer. This is a well known Octoprint issue that goes back many years.

Hmmm. That issue was closed on GitHub, and not mentioned anywhere else. I’ll try that then, and see how it goes in terms of print monitoring.

I’ve reverted back to Marlin because I really needed to get this print done, so it will take a while to test again.