Extruder stops after a few minutes but x,y,z continue normally

[sricha1217]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

Printer stops extruding part way through a print even though the hotend keeps moving in x, y, and z perfectly normally.

Here are all the details that I think could be useful to any kind person who may have advice:

System Configuration:
-The printer is a Sapphire Plus with a Robin Nano v1.2 board.
-All drivers are TMC 2208.
-Firmware is Marlin 2.0.x (if the “x” could be significant, I’ll look it up.)
-Slicer software is Cura v. 4.13.

Details of problem:
-The amount of time before it stops extruding is anywhere from about 1 minute to 10 minutes after the print starts but is never exactly the same with consecutive prints and doesn’t seem to be related to a layer change or an exact point in the gcode.
-The amount of time before it stops extruding seems to have an inverse relationship to the print speed: the higher the print speed, the longer an amount of time before it stops extruding. At 25mm/s it usually stops extruding a Benchy before or shortly after completing the 1st layer. At 50mm/s it will usually get at least to the upper deck and sometimes reach completion.
-There is no mechanical blockage or clog. When we manually command an extrusion via the touch screen, the extruder extrudes filament exactly on command.

History:
-Until this issue, the printer had been working very well since we purchased it approximately two years ago.
-The problem was noticed shortly after we re-flashed Marlin to define SERIAL_PORT to 1 in order to connect a Raspberry Pi with OctoPi to port 1 (UART header) so we could put the Pi inside the printer base, instead of connecting it externally to port 3 (USB).
-It may be relevant that, months prior to setting up OctoPi, we had configured the drivers (TMC2208’s) to be in uart mode: we removed the jumpers from the Robin Nano board, shorted the appropriate driver pins, connected the shorted junctions to the uart header, and set the configuration file to “TMC2208”, (not “TMC2208_STANDALONE”) for each driver board. So, to free up port 1 for OctoPi, we had to reverse that process to put the drivers back into standalone mode: we disconnected the driver uart lines, removed the associated jumpers from the driver boards, reinstalled the jumpers on the Robin Nano board and set the configuration file back to “TMC2208_STANDALONE” mode. I’ve mentioned the reversal from UART back to STANDALONE only because we couldn’t find information about how to do it. So if there is any special “reset” that should be performed to revert drivers from UART back to STANDALONE, we haven’t done it.

Troubleshooting:
-We tried changing SERIAL_PORT back to 3 and printing via USB (with OctoPi disconnected), but the problem continued without any change.
-We have not tried putting the drivers back into UART mode.
-To check for intermittent connections, we tried sending a very long extrusion command and jiggling every connection, but it didn’t have any effect.
-To check if the extruder driver was overheating, we tried reducing the driver current and blowing lots of air over the heatsinks during a print. No change.
-We checked the gcode files for some corruption, but extrusion amounts appear after the move coordinates for each “G1” command exactly as they should.
-We tried swapping drivers around (all from the installed set because we don’t have extras). No change.
-We tried changing UI display modes between “TFT_LVGL_UI” and “TFT_COLOR_UI” because we heard of a bug with TFT_LVGL_UI in Marlin 2.0.x versions. No change.

Could an accidental change to something in the configuration files cause the extruder to stop extruding in mid print without affecting the other movements? (Unfortunately, we didn’t make a backup copy of the configuration files, because we thought the “SERIAL_PORT” and “STANDALONE” changes were trivial enough not to require a backup.)

Could the drivers have required some “reset” command via UART before reverting them back to STANDALONE?

Any ideas would be immensely appreciated.

Thank you.

Bug Timeline

New issue

Expected behavior

I expected extruder to continue extruding throughout entire print.

Actual behavior

Extruder stopped extruding part way through print, even though x,y,z moves continued normally.

Steps to Reproduce

Print.

Version of Marlin Firmware

Marlin -bugfix2.0.x-MKS-2.1.3 (Apr 13 2022 08:30:55)

Printer model

Sapphire Plus

Electronics

Robin Nano 1.2, TMC2208 drivers

Add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

OctoPrint

Additional information & file uploads

ConfigFiles_2022.04.13.zip

[madurani]

I think, that your problem isn't related to SW, but is related to jam(Heat Creep) of filament in store room of the nozzle or in heatbreak. The problem can be partly the clogged nozzle, not enough inserted bowden in hotend or not enough cooling of hotend.
Filament does not leave from heatbreak quickly enough and gets overheated. Consequently it gets softer and begins to clog. The filament stops streaming to nozzle.
I had the same issue. The printer began to print properly, but after some time the filament stopped streaming via nozzle.
My solution was: to clean or change the nozzle, replace the fan (hotend's fan, not print's fan), align of the bowden and properly inserting to hotend, closely to the nozzle (without space) .
https://3dprintguides.com/2020/05/how-to-clean-a-clogged-3d-printer-nozzle/
https://www.3dfuel.com/blogs/news/fighting-and-winning-against-heat-creep-in-3d-printers

[sricha1217]

A clogged nozzle was my first thought also, but that wasn't the case.

It turns out that one of my prime suspicions proved correct (which is very rare for me): the problem WAS due to the fact that I tried to revert the driver mode from UART back to STANDALONE.

When I put the driver back in to UART mode, the extruder functioned normally, even at low speeds. So, apparently, once a driver is converted to UART mode, it cannot be reverted back to STANDALONE - or, it requires resetting something that I'm not aware of.

But, that's not an issue with Marlin.

Resolved.

[phcay]

This problem occurs when the TMC2208 or TMC2225 are used with LINEAR_ADVANCE enabled and the TMCs for extruders are in StealthChop mode (default mode when in STANDALONE). The too rapid changes that this generates create, at certain times, micro-shorts on their mosfet bridge and when the TMC detects it, it puts itself out of service, until it is deactivated / reactivated (ENABLE pin) .
The TMC2225 have a pin to enable/disable StealthChop mode, which I used on a Tronxy motherboard with the same problem (switch + 10k Resistor between this pin and the VIN pin), but I don't believe the TMC2208 have one.
It can also be deactivated in software by progamming the TMC at the OTP (One Time Programming) level, but it is definitive (no rollback possible) for the STANDALONE mode, afterwards, it can only be reactivated temporarily by UART afterwards.
Of course, in UART you can do it even hot in the TMC configuration menu (StealthChop/SpreadCycle mode).
The easiest way, when you have changeable drivers, is to put a driver that better supports LINEAR_ADVANCE with StealthChop, such as the TMC2209 (or similar TMC2226...), or a driver that doesn't do StealthChop (eg A4988) .
Otherwise, LINEAR_ADVANCE must be disabled.

[sricha1217]

I did have “LINEAR_ADVANCE” enabled, but it wasn’t being used: “K=0”. Could that still have been the problem? Regardless, it seems to have gone away completely when I put the extruder driver back in UART mode and selected SpreadCycle. (I say “seems to”because I still have surface quality issues, but I think that’s an unrelated issue. )

Thanks!

[phcay]

It seems to me that when I had faced the problem (on Marlin 2.0.7.x of memory), zeroing the K factor was not enough to inhibit the problem, I really had to remove the LINEAR_ADVANCE function.
However for me, doing without LINEAR_ADVANCE was not possible in terms of print quality. That's why I put the Tronxy card under Marlin at the time.
The SpreadCycle mode has a bad impact on the surface quality (artifacts) especially when used for the X and Y Axes. On the Z and E axes it is not significant. So remember to activate StealthChop on the X and Y axes if this is not the case. If they are in STANDALONE, it is normally already the case.