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

Can anyone think of a cause for a printer to stop 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!

Edited 1 time(s). Last edit at 04/23/2022 11:24AM by satellite1217.

Potentially dumb question: have you checked the extruder temperature when it stops extruding?

I had a similar problem shortly after I started 3d printing, where the fan was over-cooling the extruder head, resulting in the temperature dropping below the minimum temperature set in the Marlin configuration. All the motion worked, but the extruder didn't, just as you describe. This happened especially when on the initial layers, where the cold air was bouncing off the build plate and adding to the problem. This was solved by reducing the fan speed, together with better nozzles.

Actually, that's not a dumb question in the slightest. You're absolutely correct that that's what would happen, and I saw that a long time ago when PID values were way off. And temperature stability IS something that I could have unintentionally changed, by re-flashing the firmware because it wouldn't have kept whatever PID values it was using before the re-flash. Although I always do an auto-tune after re-flashing for exactly that reason, it may not have picked the same values that were working before the re-flash. And there are small changes we've made over the last few months that may have made it so that we were just "lucky" that the previous PID values were working and may also have made it impossible for the autotune to set values that would result in enough stability. That's a lot of "maybe"'s, but it's one theory that isn't contradicted by what we already know, so thank you! I think Marlin allows someone to widen the acceptable deviation from the setpoint. I'll try making that very large (just to test the theory.)

Quote
satellite1217
Actually, that's not a dumb question in the slightest. You're absolutely correct that that's what would happen, and I saw that a long time ago when PID values were way off. And temperature stability IS something that I could have unintentionally changed, by re-flashing the firmware because it wouldn't have kept whatever PID values it was using before the re-flash. Although I always do an auto-tune after re-flashing for exactly that reason, it may not have picked the same values that were working before the re-flash. And there are small changes we've made over the last few months that may have made it so that we were just "lucky" that the previous PID values were working and may also have made it impossible for the autotune to set values that would result in enough stability. That's a lot of "maybe"'s, but it's one theory that isn't contradicted by what we already know, so thank you! I think Marlin allows someone to widen the acceptable deviation from the setpoint. I'll try making that very large (just to test the theory.)

The latest Marlin includes MPC (Model Prediction Control) as a replacement for PID on the hot end. It puts PID to shame, at least for me.

I increased the THERMAL_PROTECTION_HYSTERESIS value from 4 to 15, but the behavior hasn't changed. And, it's clear from the graphs that the temperature variations aren't anywhere near 15 degrees. So the problem doesn't seem to be that it's tripping a temperature limit unless there's another that I'm not aware of.
The model prediction control thermal management sounds very interesting. Once this is problem is solved I'm looking forward to trying that. I'd like to see it controlling temperature tighter than it does.

Update: Making progress. The problem IS related to the drivers in some way. When I installed a set of TMC2208 drivers from someone else's printer, the printer worked perfectly: extrusion continued throughout the print, even when printing at slow speeds. When I re-installed any of my TMC2208 drivers in the "E0" location, the problem returned: the extruder stopped extruding part way through the print, even though x,y,z moves continued normally. I verified that "Vref" values of my drivers and the borrowed drivers were the same (1.2V).

The driver chip may be over heating and going into thermal shutdown. Why does one do it and not the other? You're probably operating at the edge and one goes over and the other doesn't. Try turning the current down a bit and see if it still stops working.

Those little modules suck, TMC drivers or not.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

I'm going to call this problem "solved".

The problem - which was the extruder stopping mid print with a weird, inverse relationship to print speed - was:

Once a driver has been converted to UART mode, it cannot be converted back to STANDALONE mode - or at least it requires that something be cleared/undone which I'm not aware of.

The "extruder stopping" problem ended when I put the took the driver back out of STANDALONE mode and put it back in to UART mode: I removed the jumpers from the Robin Nano board, shorted the appropriate driver pins, connected the shorted junction to the uart header, and set the configuration file to “TMC2208”, (not “TMC2208_STANDALONE”).

I hope this thread proves helpful to someone in the future. Thanks to everyone for your comments and advice.

Thanks for posting the solution.