SanneM

There is no one GCode to bed compensation on UM3 or S-Line because the compensation to the GCode is done outside of Marlin. On UM3 you can set the frequency to always perform a bed measurement instead of weekly, which would achieve what you want.

Fortunately the cooldown steps that were previously "skippable" are no longer blocking and you are able to press confirm removal now when previously you were able to press "skip cooldown". The machine still needs to perform some steps at the end of a print to get itself into a known and stable configuration, they are the same as the steps that were not skippable before.

From the video it looks like the printer is doing the bed measurement well, but clearly the print itself is not good, that is quite strange. Is the issue always the same in the same location? I am wondering if the glass-plate itself may not be flat enough to be compensated well by the compensation algorithm. If the area which is printed too close to the bed isn't close to any of the bed measurement locations, then this would also hint at the glass plate being very un-flat.

With FW 8.2.1 release last week we have changed the ER80 behavior so it will not stop a print. We hope this addresses your issues, and are interested in your feedback. If you still experience frequent air manager connection warnings then please contact support.

In firmware 8.2 we have improved the network logging when storing log files on USB We did this so that we can better debug issues like the one you are experiencing If it is possible for you, then please update to Firmware 8.2 and share logs with your service contact after you see the issue occurring.

We are aware of the issue and will prevent this from stopping a print in the upcoming firmware release Apologies for the inconveniences, we take this feedback seriously

As a first course of action, please follow the advice on ultimaker.com/ER80 It is possible the issue persists, we are aware that there are ER80 occurrences on printers that cannot be solved by following the steps on the support page, and that this is a very frustrating user experience. We are taking this issue seriously and are investigating it. Due to the nature of the issue it is hard to say when it can be fixed, but we are committing to making it so ER80 cannot cause print failures.

The sensor data you see in the graph by Tom is pure raw sensor data from your printer. That sensor data doesn't change from firmware to firmware. The data from your printer shows that there is an issue in the electronics sometimes, though most of the times it performs well. Perhaps there is a difference between 7.1.3 and 8.x that causes the printer to raise an error sooner, I don't think so but I could be wrong. Regardless your printer will need servicing if the sensor is doing that.

Vreemd dat de knop ontbreekt, gelukkig kan het zonder de knop ook, door zelf de contactjes te verbinden, maar dat vergt wel wat meer finesse: Door tijdelijk 2 schuin tegen over elkaar liggende contactjes te verbinden van de 4 contactjes voor de RECOVERY knop, zal het werken alsof de knop ingedrukt is, zie als voorbeeld de afbeelding Dit kan door bijvoorbeeld met een pincet (of iets anders geleidend) de 2 contactjes tijdelijk te verbinden

Yes that can indeed fix this error as well. There are multiple failure modes that produce the error in the picture If you see the error in the picture it doesn't mean that it was because of the new firmware, but if you suddenly started seeing it when going to 7.0.4 it might be because of the update

Hi @FishGuy! That is a very interesting failure mode, do you still have the logs from when this failed? Those would be interesting for analysis, perhaps the algorithm can be tuned do detect this case more specifically

We are still working on fine tuning at what numeric value the sensor should be considered broken, so unfortunately the message is really vague at the moment Why we did choose to show this message on the display already, is so that you can share the number with support I expect that the message will have more clear feedback in 2 firmware updates from now, until then if you are experiencing issues with bed measurement please contact support and share this number with them That said I can say that 2.6 is really good, and 44 or 35 definitely is reason to contact support if you have issues with bed measurement, as your print head circuit board might need replacement