Diagnosing Thermal Runaway of Hot End caused by wall thickness.

I have three custom printers that are running Marlin 1.1.7 on a Arduino Mega 2560 with 4988 shields. The steppers are all 1.8s but are from multiple sources. I am using E3D clones for hot ends and near constant 100% fan speed for part cooling.

I have printed numerous prints on each machine and am still printing strong. Lately I have been designing organizers for the Runebound game which I have been posting on Thingiverse. The issue I am having is that some of the designs have caused a thermal runaway (TR) error just prior to or shortly after starting thin walled sections/layers. I have repeated this error multiple times and under varying conditions. I know its not really a thermal runaway caused by a failure as I have repeatedly completed other prints between the bad prints.

Initially, I started chasing the issue as a thermistor issue. Found no issue with those. I them looked at the hot end itself but, as I pointed out, the printer works just fine with other prints. I then looked at the operation of the printer hot end temp using the graphical output in Octoprint. In general the temp control looks good though the larger walled or infill sections but one the print transitions into the thin wall section it goes to crap. The ability of the printer to regulate the temperature seems to fail.

I initially though the issue had something to do with the Cura 3.6.0 update, as I only started having the issue just after the update. I posted on the Cura forums, but no one seems to understand what the issue is or could be. Part of the reason I thought it might be Cura is some of the sliced files for the thin walled items show a much bigger size than expected. For example when slicing a lid (hollow box) with a wall thickness of 3-mm the file size received was 4,000-kb, but the same sized box designed with a wall thickness of 1-mm yielded a file size of 16,000-kb. This seemed counter intuitive. But after more though, I think its because of the infill grid has to bounce so much more to get the infill in, and every bounce is a change in direction requiring a new g-code entry.

This realization leads me to think Cura isn't the issue. So here is my actual question. Is there a processing capacity limit on the RAMPS 1.4 boards that can be reached from just running a quick series of g-code movements? I realize all processors have a limit, I am just wondering if the rapid series of g-code entries could cause a lag in the controller resulting in a lag in the processing of the temperature signal.

The other question is, would a rapid movement sequence draw more current than a smooth sequence? Basically, could my 12V power supply be current starving the hot end due to an increased draw by the motors? I ask this as my understanding of a stepper motor is that it makes little difference which direction it moves, a step is a step and the current required to produce the step is the same. I know in a normal 3-phase motor the staring current draw is a lot more than running current, but I expect that in a stepper its almost always a starting current since the motor doesn't free wheel.

Regardless, I have noted a few things with thin walls. I am more likely to get the error with a wall thickness that is a multiple of the nozzle diameter (0.4) than not. Meaning that I have found a 1-mm wall works better (prints longer) than a 1.2-mm wall (fails almost immediately). I have noted that the issue is effecting older models that used to print without errors, specifically the DND hex dice box that used to be up on Thingiverse. I have also noted that moving the model to a different location or rotation in Cura may not only help the file size issue but can result in a completed print instead of a TR error.

Any thoughts or assistance would be appreciated. And no, I have not used a different slicer yet, though I intend to soon.

LFG

Edited 1 time(s). Last edit at 02/02/2019 01:45PM by LFG.

It's not only the processing of the GCodes that uses up processor time, reading the GCodes from either the serial interface or the SD card involves a lot of processor attention in 8-bit electronics. It's a while since I looked at Marlin source code, but it's probably having to service one interrupt per character, whether you are reading from serial or SD card. Or it might be sitting in a tight loop when reading from the SD card. Either way, that's a lot of processing. So I'm not surprised if the processor is getting overloaded, which seems likely from the symptoms you describe.

You might want to post your question in the Firmware - Marlin section, in case there are firmware configuration changes that might help.

If you are printing over USB/serial, then you may find printing from SD card works better. Or not.

Otherwise, you will need to reduce printing speed, or configure your slicer not to generate such short segments.

Or you could upgrade to modern 32-bit electronics and firmware, which is not only faster but uses DMA to offload USB and SD card transfers from the processor, and a real time operating system to prioritise temperature control.

Edited 1 time(s). Last edit at 02/02/2019 05:21PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thank you dc42,

I guess I never realized that there could be an issue like this. I recently converted my printers over to Octoprint control via a PI on each machine, so it is getting the programming for the print through the USB. I am a Civil Engineer my trade so that last bit of electrical/computer programming went over my head but it would appear I need to slow my prints or refine the Marlin settings.

LFG

My finding is, that every Marlin over 1.1.6 turned out to be not stable - see all the discussions here in this forum on 1.1.7, 1.1.8 and the few peole with 1.1.9
I have the same expreience with my 2 Deltas - 1.1.6 does have much less bells and whistles, but works. Starting with 1.1.7 I never could get (reliable good) prints

I would be very interested about Marlin 2.x if it works reliable, but I do not have the time to test, neither do I have a 32bit controller

Well I think I have solved the issue but I am not happy about it.

So after reviewing everything I determined that I needed to slow down my printing speed. I was slicing with a speed of 60mm/s and have now lowered it to 45mm/s. I have not ha an issue with any more Thermal Runaways on the new slices but printing at 45mm/s is frustrating. I have determined that all this started when I had to upgrade to Cura 3.6.0 or when Octoprint updated. Both of those occurred at about the same time so I am not sure which one is the issue.

LFG

Update:

Slowing down helped but did not solve the issue. I rolled back to Cura 3.5.0 and that fixed the issue. Not sure what changed in 3.6.0 but something is either overloading the Arduino or something is bugging.

If you looked at the gcode from Cura 3.6 you'd probably see tons of tiny segments being produced for the thin wall sections. Thing wall printing in Cura is pretty broken. There's a 3rd party build with some tweaks out there. Might wanna take a look on the Cura forums for it from user Smart Avionics.

You havent got a max temp in marlin specified close to your hotend temp have you?