Weird stuttering

[yet-another-average]

I've a weird issue. Octoprint is stuttering. Never had this issue before (years with OctoPrint).
And the weirdest things are :

• stuttering is worse in safe mode
• stuttering is worse with Arc Welder
• stuttering is worse if Chromium is displaying OctoPrint on the Pi

The only way to get perfect prints is printing from SD card.

I tried many things, always one by one (no machine gun debugging)

playing with Marlin buffers, handshaking, increasing / decreasing baudrate
disabling anything that need calculations on the printer motherboard (Lin Advance, S-Curve)

Whatever I do, the printer is sounding bad, pauses (resend ratio gets one point). It is a recent issue. Maybe correlated with Cura Arachnid ? (but the gcode is fine from the SD card)
I tried an older version of OctoPrint : no difference
I tried last Marlin bugfix : no difference

Fresh OctoPi/Octoprint, on another SD card with Firmware Updater plugin only : no difference.

top does not show any memory / CPU hog.

Oh ! and the USB cable is a short shielded one, and I removed the +5V gold finger long ago.

I'm out of ideas after maybe 30 hours of testing ! The best results I got was running OctoPrint headless. This is extremely disapointing. But still getting blobs.

This makes me think that something is wrong with my Pi...

What could I explore now ?

[EDIT] things I did not do at this time : removing VNC and samba. Who knows ?

[Ewald_Ikemann]

Could you please share the systeminfo bundle.

[yet-another-average]

Yes, indeed !

octoprint-systeminfo-20220831221241.zip (160.8 KB)

You will see serial.log is an empty file ; when I enabled it, it only reported the timeouts I was seeing in the terminal while testing (correlated with the blobs of course).

"Request low latency mode on the serial port" was checked, but made no difference.

SD support was disabled in order to allow some more buffer space on the Mega2560 based MB.

[Charlie_Powell]

@yet-another-average

the printer is sounding bad, pauses (resend ratio gets one point).

If the resend ratio increases, then this suggests that there are some general communication problems. I can see in the logs the communication timeouts you mentioned, which also suggest communication issues. What seems to be happening is that OctoPrint sends a command, but it gets lost along the way and never acknowledged by the printer.

Has anything changed with the electronics near/on the printer recently? Especially with Creality printers, they can be susceptible to interference quite easily. Even stuff like nearby appliances (eg. fridges) had an impact. It sounds like your USB cable should be a good one, but maybe it is worth checking with another one if you have it? Any specification of cable could do just for a test.

[yet-another-average]

Thanks for your answer, and you could be right !

Yes, I changed something in the hardware. I recently replaced the old 1024x600 TFT I had since the begining with a gorgeous Waveshare IPS. So I dont need TouchUI anymore ; no more supported : needed a better display/touch. I reused the same cables (HDMI : a good and short one, and the micro USB I have been using since the begining for the touch interface).

Just after I read your post, I replaced the old micro USB cable with a short shielded one. You know, one of these thick blue shielded cables that often came with chinese modules. Now the printer and the LCD all use blue shielded cables (with no ferrite beads). The LCD is powered by the Pi through the touch interface (surprisingly it draws very little current !)

7inch Capacitive Touch Screen LCD (H) with Case and Toughened Glass Cover,...

The Pi itself is powered with a 5A SMPSU, direcly to the GPIO (no guts, no glory).

Now, the printer runs much smoother. Still seems to me it does not sound as smooth as with the SD card, but it is difficult to compare. Not a musician ! The test print now does not show any signs of micro stuttering (PETG, 50mm/s, 0.6mm nozzle, 0.3mm layers : artefacts can be seen easily).

This being said I will investigate a little further, as I also just changed the config.txt monitor parameters (I was reusing the previous ones...). I also changed the USB cam resolution from HD to VGA.

Tomorrow, some more testing : the problem has to be reproduced before we can say the culprit is this poor old little cable that caused no problems for years ! Will let you informed.

Unfortunately, I don't have a spectrum analyser nor EMI probes ; it could be intersting to compare EMI from the two LCDs, and what goes to the Pi USB ports... If you play with electronics, high frequencies, and know how to roughly analyze EMI with a 200 MHz scope + FFT and a DIY probe, please let me know... The new LCD could be a strong HF source, air and/or copper !

[yet-another-average]

Update...

There are three intricated problems.

The first problem is the connection. It seems it disappears with the blue cable, and reappears with the old one. Thanks to @Charlie_Powell ! The LCD is probably not very clean !

Before I ask for help, I tested another USB cable for the mobo connection, with no success. I didn't imagine the LCD power + touch cable could be the culprit !

Problem solved.

config_hdmi_boost (in config.txt) ; it was set to 4 according to the recommandations that came with the previous LCD. I tested with the new LCD, and instead of 10 (recommended for the new LCD), I commented the line out (= no HDMI boost). Using the old USB cable, and no boost, I didn't get connection problems (and no display problems BTW). There's little information about this parameter, but we can imagine that the more boost, the more EMI... The LCD is not shielded, and the PCB layout maybe is not the best... But it is still a great display, crisp, with a very accurate touch, and it draws little current (60mA when displaying the console, 80 mA with X11)

-> Problem solved (probably part of the problem)

The second problem is not related to the Pi or OctoPrint. It is a Marlin issue : Linear Advance is too much for the Mega 2560, at least with the printing speeds I'm using and the default Cura resolution settings. Classic Jerk control has to be activated, Junction Deviation deactivated (they are mutally exclusive anyway...), Linear Advance,and S Curve have also to be deactivated. Got a 32bit mobo 2.5 years ago, still not installed... (desiging the printed enclosures...)

-> Problem solved (more or less : the printer still struggles a bit)

More testing would be needed, but such tests are extremely time consuming !

[yet-another-average]

Another update...
Was still experiencing a few resends. Rarely, but still some. With the blobs.
I put the Pi on the controller enclosure using double sided adhesive tape : this creates a earthed ground plane.
Since then, zero resends !

The stuttering was a different issue. I had the problem with a cylindric, low poly model (!!!) : Cura was creating loads of tiny moves (0.1mm), and for some reason Arc Welder (with default settings) was not working well with this model (I keep it as stress test !). Exporting the model from the CAD software as very high resolution STL (0.02mm and 0.5deg deviation), Arc Welder made a much better job. Maybe AW cannot replace loads of tiny aligned segments with a large arc, using default parameters... )

Maybe this information could help...