[BFW-6246] [ENHANCEMENT] MK4 Live Z adjust permanent

[griznold]

Enter what type of printer or upgrade the enhancement applies to.
Printer type - MK4
Optional upgrades - Orignal

Is your suggested improvement related to an existing problem? Please describe.
The live z adjust is also available for the MK4. But is not sent permanently. I like to have this feature to behave like at the MK3, where it is permanent. (Value is kept even after power reset).
The standard load cell bed leveling was not sufficient, to create a very smooth surface. And it looks like, if this varies from printer to printer, to create consistent results. So the easiest solution would be to make this setting permanent.

See discussion here:
https://forum.prusa3d.com/forum/english-forum-original-prusa-i3-mk4-hardware-firmware-and-software-help/any-way-to-change-the-z-offset/#post-675656

Describe the expected functionality
The live z adjust should be permanent stored.

[mix579]

I don't disagree with this idea but I found things to be even more complicated. The "always perfect" first layer is really not so perfect if I use a satin or textured sheet because the rough surface of those sheets seem to throw the load cell off. I need to dial Live Z manually down by about -0.025 to get good adhesion. So storing just one value in fw wouldn't really help me. What I need is a sheet menu like we had on the Mk3S — but of course that would be admission that the load cell is really not better than the old PINDA…

[griznold]

That's an important point. But physically it seems logical, that a smooth and a rough surface will lead to different results if they're probed with a big object. So even with a good contact point, the rough surface should then need more filemant to fill the small valleys.
So my hope was, that these factors were negligible, but I mainly used the satin sheet so far.

[Skaronator]

The best solution from a hardware standpoint would be if the printer automatically knew which print bed is used. This would be possible when the print sheets have a special location outside the print area where the load cell can check for a raised bump. Somewhat like a punch card reader but instead of having a hole in the sheet it would be a raised bump that could be glued for already produced sheets.

[xilni]

This applies to the 5T XL as well, for PETG with the textured sheet I have to get down to -0.125 mm for the first layer using the dial since the Z offset parameter in the slicer doesn't seem to affect anything.

[vmLOGIC]

The issue with my Prusa MK4 only occurs with the textured sheet. Using it is like playing a game of chance. This is a very frustrating limitation, especially when printing with PETG. With the Prusa Mini, I almost exclusively used the textured sheet, so I ordered it for the MK4 as well. Apparently, without reason.
I would classify the issue here not as an enhancement but as an error.

[peterjhl]

+1

[stefanbayer1]

Having the same exact issue. Why does no one at Prusa adress this. Also the support was not helpful at all. I would say my MK3S+ was better in terms of print quality and reliability of the first layer than my Prusa MK4 is after 3 moths of use.

[vmLOGIC]

Exactly! This question has been left hanging for 4 months now, and Prusa hasn't bothered to respond in any way. It's truly infuriating! Yesterday, I thought I'd give it another shot. After all, there have been firmware updates in the meantime. Your comment just confirms that there has been no improvement. I'll soon have to shell out for a new PEI shield because PETG is slowly but surely wrecking the old one.

[pjvenda]

Considering the poor adhesion issues on the satin and textured surface, it would be most welcome to have indexable permanent z-offsets stored on the printer.

[ViceVerus]

I own an XL and have been chasing an issue for months. I had gaps in the first layer on all first layer infill types, moving to the 0.4mm from 0.6mm minimised the issue to a reasonable level with monotonic. I like to use the Hilbert as it can minimise visibility of the lines to nearly nothing. This worked on the MK3S very well and I produced XXXs of parts with perfection. This was by manual Z calibration.

I have found in general that the Load Cell is very repeatable but I don't think it is that accurate. The printer assumes perfect accuracy and does not allow you to override. 0.05-0.02mm even with monotonic getting rid of the tinny pinholes at the point it reaches the perimeter.

I would really like this to be raised further up the priority list for all printer types that use the Load Cell

[github-actions]

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.

[vmLOGIC]

Before this issue is closed, a statement from Prusa would be appreciated. Why should we write issues and contribute to product improvement if no one reads them?!

[ltlowe]

I was not even aware we can do a live Z adjustment on the MK4, but if the force sensor isn't giving the correct values, it would be a nice backup. In general I've been having issues getting the first layer correct on my MK4, fw 6.02 when using a 0.6mm nozzle. Similar issues I have found and added too are #3264 and prusa3d/PrusaSlicer#11271

[m00dawg]

Been at this for 2 weeks now. After numerous live chats, a replacement loadcell, factory resets, firmware upgrades, I have found that just bumping the z-height to +0.04 seems to remedy my first layer issues. Maybe it's something with my particular filament but while the XL seems to have a great first layer stock, on my MK4 it's just too close to the bed (consistently). It's "fine" probably for most prints that don't heavily rely on what the bottom looks like, but it makes it look kind of ugly with inconsistent lines and gaps. This is because it's displacing filament being too close to the bed.

Bumping the z-height 0.04 solves this and seems to do so consistently. Since I can't save the offset on the printer, I'm forced to do that in PrusaSlicer which means I might have to have multiple sliced models between printers. This is far from ideal. I'm not sure why Prusa is so stubborn about not offering this. If it's a question of not having new users mess something up, hide it behind an advanced users menu with a disclaimer. Invalidate my warranty if you must, just give me this feature.

Everything else about the MK4s has been glorious but it just surprises me the MK3s in this case is actually better. Granted my use case may not match most but taking away this feature is just a step backwards. And it cost Prusa money and time (in having to deal with all my live chats and loadcell replacement) which could have been avoided.

[griznold]

So I'm still using the Offset in the slicer for two MK4 now. I would really appreciate the simplest solution, so that each printer can be adjusted and keeps the value.
Even an additional warning can be placed, to that No one ist doing this by accident.

I would think, that a more complex solution as a function of material, sheet type and speed would be maybe more a problem itself, than an easy solution.

[m00dawg]

This issue is the reason I haven't yet bought another MK4, specifically related to griznold's use case. I have just way too many models to slice to have to do that for every single printer just because they have varying z-offsets that I cannot adjust on the printer itself. It's a pretty big deal and I really wish this would get more attention from Prusa.

[stefanbayer1]

Left Prusa 6 months ago for good- it seems like good software was never their focus!
Much happier with the Bambu Lab A1

[m00dawg]

Left Prusa 6 months ago for good- it seems like good software was never their focus! Much happier with the Bambu Lab A1

Might be getting off-topic but Bambu's behavior and perspective on things like open source are generally incompatible with my preferences. Prusa has taken some steps backward here as well but feels in response to Slice, Bambu, and even E3D, getting into the patent game. Something that held back 3D printing for 20+ years and not a road I want to walk down.

That doesn't leave Prusa off the hook here. This bug/feature req is a pretty huge quality of life improvement for us folks that run print farms and/or know our way around printers. At worst, if Prusa just decides this is not a feature they want to fix, I'll continue my investment towards Vorons. I think the Mk4 and XL easily have better quality out of the box for less faff but on the Vorons I don't have to reslice for every single printer once I have things dialed in and that's a really important need for me.

[m00dawg]

Just as an update, did another live chat to see if they can at least reassign this issue since the person it is assigned to doesn't seem active on GH (no activity since Feb). They initially said they weren't going to implement this as needing to adjust the layer height indicates a problem (based on my experience I disagree), but then simply said the devs were aware and they might in the future but no guarantees.

Very frustrating as I'd be buying MK4s today were this bug fixed. At present, I'll be evaluating expanding my fleet of Vorons instead I suspect. They're much more fiddly to build and calibrate compared to the MK4 but once built I can set first layer heights since, you know, any printer should have that feature...

[stefanbayer1]

Get one Bambu Lab A1 and never look back again …

[CZDanol]

Hey guys, very sorry that this is taking so long. We were having a discussion about this recently, and we will try to figure something out. We understand that this is a valid request.

Internal ticket: BFW-6246

[m00dawg]

Relates to #4254

[m00dawg]

Untested changes which might get/set z-offsets. Maybe:

#4269

In order to test that I'd have to break the void warranty notch on my mainboard so I thought I'd start here to see if this gets Prusa's attention.

[m00dawg]

@CZDanol Ah just saw your updates. Thank you for taking the time to look at this! I've very appreciated!

I'm not sure if the above PR will help. First time looking at this codebase and there's quite a lot going on but hopefully it provides some food for thought.

I noticed there's code in there for saving live-Z in the case of using multiple steel sheets, but some assertions to cause build failures when trying to enable that with some warnings about it doing bad things on the XL. That's why I opted to drop that approach and just see if I can save the z-adjustment itself without trying to enable the steels sheets option on the MK4.

I suspect Prusa, if this feature gets supported (please do! It's the only thing preventing me from buying more MK4s), it may want to put it behind an advanced user dialog with a buncha warnings. I didn't at all look into that since the above PR was originally my nuclear option in getting something working (if I'm willing to void my warranty) and if it was just for my own personal fork, I wouldn't need to bother with that.

[CZDanol]

@m00dawg thank you for doing the PR. My intuition is however telling me that we'll need to put the hooks in different places. I'll have to look at how SteelSheets are implemented and will probably do it +- the same way, as that already has been tested :)

[m00dawg]

@CZDanol Yeah I'd love to have the steel sheets option with being able to save offsets per sheet. That would be the brightest timeline feature, although saving a global z-offset would cover about 90% of my needs as well. I'd be happy to see either! Thank you again for taking a look into this feature request! <3

[CZDanol]

Enabling SteelSheets would probably need a lot of considerations (especially how to "hide" it from the majority of users that don't really need it), so that would be hard to push for atm. But making the Live Z optionally permanent should be rather straighforward, so I'll rather try pushing for that.

[JoeScotty]

To support this with measured values:
Got the MK4S a few weeks ago and having the same problem.
Currently helping myself by adding Z Offset at prusaslicer, which not the place to fix hardware/firmware issues.

Tested the first layer thickness using the following sample using the smooth build plate.

and measured the line thickness using a high quality micrometer.
The result is this table:

@ Prusa: It is definitely necessary to offer a persistent Z-offset

[m00dawg]

@CZDanol First congrats on the baby Core! That's very exciting!

Second, I wanted to touch base to see if there was anything you needed from me based on my PR or otherwise anything else in terms of testing or what have you? With the Core and MK4s sale price, I've been compelling to get more Prusa's but also a bit apprehensive since the z-height issue will end up getting more complicated.

I heard that Prusa no longer considers breaking the firmware tab on the mainboard a warranty voiding offense. Do you know if that's actually true? I haven't been able to test my own PR because I was fearful of the warranty issue.

[CZDanol]

@m00dawg thanks :)

For the persistent live Z option, I'm sorry to say that it is currently stuck on people from our product department to give a decision :/

Regarding the PR:

1. float z_offset = config_store().get_z_offset(); in WindowLiveAdjustZ::Change(int dif) doesn't do what you think
2. marlin_client Event::Startup is not the right place to put the set_z_offset(config_store().get_z_offset());
3. We will have to check how this would interact with the crash_s class that handles storing and restoring a lot of print data over crashes and power panic.
4. Whether the Z offset should be persistent or not will definitely have to be optional

To be frank, blind shots like this don't really help (well, they do motivate us a bit :)) – we cannot merge it and going through everything with the PR author in a non-trivial problem like this would take more effort than if we did the whole task in-house. I hope that this doesn't sound too harsh and if so, I'm sorry.

Breaking the appendix indeed no longer voids your warranty. It is explicitly stated in this blog article: https://blog.prusa3d.com/introducing-prusa-core-one-fully-enclosed-corexy-3d-printer-with-active-temperature-control_105477/

Historically, in order to flash custom firmware to all our printers equipped with the Buddy board you had to break a special seal and that meant losing your warranty. Not anymore: we’re making a huge positive change with the aim to make the printer even more community-friendly and motivate developers to dig into the code and come up with all sorts of tweaks and customizations. From now on, breaking the seal won’t void your warranty, so you are free to flash custom firmware. However, since there is no way for us to verify or test every single custom firmware on the internet, we disclaim liability for any kind of damage or harm a printer with a broken seal may cause.

[mix579]

In all fairness, a permanent Live Z adjustment (while certainly useful if available) would be just a kludge to deal with a more profound issue, that there's something fundamentally wrong about the load cell hw/fw infrastructure. Looks like it works reasonably with PLA but not other materials, and better with smooth sheets (which I for one haven't used in many years) and less so with satin and textured. I also noticed that after the Mk4S upgrade my Mk4's now need a "positive" offset to avoid ripples as opposed to a negative offset before. In some other thread someone found that after switching from Obxidian back to brass, the problem seemed to have gone away.

What that all tells me is that it's a more complicated issue than applying one fixed offset, and that Prusa should spend some quality time to dig deep into it so that the promise of an "always perfect" first layer is actually fulfilled, regardless of material, sheet type, and nozzle type.

[m00dawg]

I take a different view than @mix579, though will admit, I don't have to adjust live-Z on my XL. It's where it needs to be. My live-Z on my MK4 is consistent (post adjustment) so my feeling is deciding on what "wrong" means. I feel like maybe Joe (or someone in product) is still overly stubborn with stating it doesn't need adjustment. I think my feeling is that, if it's off by a little but otherwise consistent (which both my load cells in my MK4 have been), it's perfectly acceptable. I would neither want the hassle of having to swap it out or the increased landfill for what is otherwise working.

@CZDanol Thank you for the candid and transparent explanation! That is very appreciated!

I really really hope Product makes the right call there. I uhh...well I've worked at companies enough to know I shouldn't hold my breath :P I guess Prusa is getting to be pretty big! This is a good thing though certainly has trade-offs and being able to respond to customer requests like this is among them. Is what it is.

I thank you however for the hints on where I might go to work on the firmware. If I no longer void a warranty breaking the tab, it at least means, in the absolute worst case, I can maintain my own fork that does give me the save-able live Z. Or some of us that really want this feature can get together and try to figure out a community fork. I'd imagine that's not what Prusa wants (I don't either) so crossing fingers Product makes what I'd argue is the right call. I'm a bit sad Prusa printer hardware isn't nearly as open as it was but I definitely applaud that the firmware continues to be since it gives us a solution where there otherwise might be none.

For now I'll keep holding my breath a little longer in hopes the Prusa product team surprises us with a great Holiday present (I mean other than the Core, which is itself a nice holiday present for sure!)

[m00dawg]

@CZDanol I assume the answer is no but since it is the Holidays, had the Product folks perhaps given us a 🎁 based on your previous update that they are evaluating it (but have yet to make a decision)?

Related, does Prusa offer feature bounties (paying for features)? If the feature is better done in house, that might be a route I would be willing to explore.

[Prusa-Support]

Thanks for the support but paying for features is not an option at the moment.

At the current state of the art, it would be extremely rare to receive direct contributions consistent with our ever-rising standards. However, we surely appreciate and keep on the radar community contributions and active contributors.
We generously contribute to the community and surely appreciate community contributions, even when the contribution is not directly directed to us.

As a side note, warranty simply covers factory faulty parts, including when our own firmware is part of the fault. Forking the firmware project and using custom firmware won't void the warranty as long as it won't produce damage of course, so please do at your own risk.

Back to the feature request, we don't really need outsourcing for porting this feature from MK3 to MK4/XL but to consider our steps very carefully before changing any single piece of firmware.
Moreover, this specific feature request may potentially suck up and overcomplicate potential problems with the printer which, according to our tests, doesn't really require tweaking of the first layer offset under normal circumstances.

Our Product team really simply needs to think this through carefully, and the same applies oftentimes to many big or small internal implementations, and again with pretty much all of the many "foreign requests".

I'm sorry for not bringing news. This may take some time.

Michele Moramarco
Prusa Research