[BUG]Stock MK3S Thermal Anomaly issues during bridging and infill

[E-Extrude]

Fully stock MK3S with 0.4 nozzle 3.12.1 for MK3S

No MMU or other devices connected. Print run through the SD card.

From the 3.12.0 Beta release to the 3.12.1 no other calibration was required to the thermal model. Thermal anomaly triggered and printer beeps during bridging and infill printing only. Object has been sliced with PrusaSlicer 2.5.0 with classic perimeter generation, detect bridging perimeters and thick bridging enabled. Default extrusion width of 0.4mm, bridge flow ratio of 0.95 with speed of 30mm/s. Infill 0.45mm width and at 120mm/s.

-The alarm is triggered much sooner in the print when in Stealth mode. -Only tested with PLA currently and hot end is set to 220. Printer is not in an enclosure and ambient temperature is 14C

-I didn't experience any thermal anomalies with the 3.12.0 Beta FW

-My current work around without ending the print is to reduce the print speed by 20%

To Reproduce Test print a model with infill and bridging requirements, set slicing settings as mentioned above or faster.

Could there be a thermal anomaly override in the 'Tune' menu to disengage it?

Fuselages_0.2mm_PLA_MK3S_8h8m.gcode.txt ^delete .txt extension

[wavexx]

Could you post the 3mf model or g-code that causes this?

Also, I'm kind of surprised stealth makes any difference (in fact, stealth limits acceleration, so if anything I would expect the opposite to happen? just a thought)

[leptun]

@wavexx Maybe longer period with the fan at 100% causing a larger drop in temperatures? The accelerations and reduced speeds shouldn't matter since the bridges are printed slowly anyway. The initial comment was also updated with the gcode (fyi).

[wavexx]

I wouldn't think so, the calibration is done at 100% fan for 60 seconds.

One suspicion I had for bridging is that the fan speed is changed for short bursts, but obviously the fan has inertia we don't handle at all just like fan checking. For for PLA the fan is usually at 100% all the time though, so this theory goes down the drain.

Maybe we're draining more power in stealth/high-speed and the heater is dropping in temperature at high flow?

[wavexx]

@E-Extrude do you by chance have the possibility to measure the voltage on the einsy on the 24V line with a multimeter while heating the nozzle?

Another question is if you could log the serial output of the printer while doing the print? We can enable extended logging and have a more detailed look.

[leptun]

@E-Extrude For measuring the voltage you can go to Support->Voltages. Try to compare the PWR voltage between the printer being idle and the hotend running at 100% power (so basically heating up). If that doesn't change too much (a few milivolts is fine), then also try to see if there is any more severe variation of this value during the print.

[E-Extrude]

@wavexx I don't have access to a multimeter but have attempted your other query. It isn't something I've done before and following the guide here https://help.prusa3d.com/article/logging-data-over-serial-line-mmu2s_355360 when launching the file with powershell, it flashes up and then disappears. I don't have any experience with this :(

@leptun I have watched the voltage through the menu. On ambient idle 23.8v, on heat up 23.7, holding temperature 23.8v. During printing it flickers between 23.8v and 23.9v. And when an anomaly is detected it still reads 23.8/9v But its during that time [an anomaly] when the hot end temp dips due to the higher extrusion flow. I don't understand how this is an issue now and It didn't arise with 3.12.0FW.

[wavexx]

Ok so voltage looks perfect.

I don't understand how this is an issue now and It didn't arise with 3.12.0FW.

So do I understand it right that you already enabled the thermal model with 3.12.0, but somehow this issue appeared only in 3.12.1?

[E-Extrude]

Correct

Some lingering bad data from the calibration?

[wavexx]

That is strange, it shouldn't be really. I need to have a deeper look if there is anything which could possibly be related.

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[github-actions[bot]]

This issue has been closed due to lack of recent activity.