RE: Any way to change the Z Offset?
Why they won't give you a Z-offset calibration on the machine really is baffling.
I found, now that I have 4 MK4 machines, that one of them was really far off, but at some point I loosened all of the screws that attached to the load cell, and all of a sudden it worked much better. It may be worth removing the front fan, loosening up all of the screws, and tightening things down again, maybe not quite as tight, and see if that helps.
I also had one unit that just wouldn't level correctly, even after trying this. I ordered a new load cell part and replaced it, which solved the issue.
RE: Any way to change the Z Offset?
Why they won't give you a Z-offset calibration on the machine really is baffling.
I found, now that I have 4 MK4 machines, that one of them was really far off, but at some point I loosened all of the screws that attached to the load cell, and all of a sudden it worked much better. It may be worth removing the front fan, loosening up all of the screws, and tightening things down again, maybe not quite as tight, and see if that helps.
I also had one unit that just wouldn't level correctly, even after trying this. I ordered a new load cell part and replaced it, which solved the issue.
The weird part is I have to adjust the Z-height up (so the nozzle is further from the bed) and I would have thought a malfunctioning load cell would be the opposite. Next time I need to do maintenance I'll try the screw trick, thanks for the tip! At present, it's beautifully consistent with that 0.035 offset which is why I'm apprehensive about Prusa saying it's an issue with the load cell (which I've already replaced once). If there's just variance in the load cells, that seems like an even bigger reason to be able to adjust the z offset.
I haven't used RTOS outside of some basic examples from the main FreeRTOS tutorials, but I might just grab the firmware and see if I can sort out what it would take to save and load the z-offset setting. In Arduino that would have been pretty easy so maybe it won't be so bad with the MK4 firmware/RTOS. If it's workable then I can maintain a forked version and at least if I can save the value I can use the fork on my printers and then just have to maintain it. And I can submit an actual PR to the main firmware, though it seems unlikely Prusa's ultra-stubbornness would cause it to be accepted.
RE: Any way to change the Z Offset?
Self update fail but I forked the firmware and started digging around and found some interesting things:
https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/8a788ae4e23d0fc79cf15c4c2dde05168b95b6bb/src/gui/dialogs/liveadjust_z.cpp#L88
https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/8a788ae4e23d0fc79cf15c4c2dde05168b95b6bb/src/common/SteelSheets.cpp#L50
If I'm reading all that right, it looks like Z-offset might be getting saved in cases where there are multiple sheet profiles. Sheet profiles exist for the MK3.5 it looks like but not the MK4 (at least it's not enabled on mine and I believe I have the latest firmware). I'm gonna keep poking around to see what I can find.
RE: Any way to change the Z Offset?
Still digging but after poking around the firmware it sounds like Prusa isn't being all that transparent in my opinion. I found some static_assert lines which causes the build to stop, such as:
#if (HAS_SHEET_SUPPORT())
static_assert(!HAS_LOADCELL(), "This caused major issues on XL.");
// Sheet[0] is used both as default sheet and as storage for z offset set by LiveAdjust Z. XL have had and issue that caused the tool offset calibration to fail due to aforementioned z offset. Uncalibrated value being float:max caused z offset to be set to 2 mm which lead to printer missing the calibration pin by almost 2 whole mm. This happens to all XLs that do not have a LiveAdjust Z value set and therefore use the default value.
That mentions the XL but it still bails when trying to build the MK4 firmware. Less important is that it fails and more important is the message above. It implies at least at one point they *were* storing live adjust Z values, just doing so via sheet profiles. This matches what I'm seeing in the firmware.
I'm trying to see if I can get the sheets feature working because all the load/save value stuff already works there instead of trying dig through all the abstraction layers for loading/storing for the EEPROM.