Initial layer height / z-offset on UM S5

[gandy 10]

Our new UM S5 arrived a week ago and from day one we've got an inconsistency in the height of the initial layer. We've tried printing Strong PLA, Nylon and TPU (all from Ultimaker) and on all materials, the first layer was of a consistent 0.16 mm height instead of the 0.2 mm specified in Cura. Same happens with PVA on the second printcore. Consequently, we need to reduce the matierial flow of the first layer to 80% to not get a totally overextruded first layer.

 

We ran the manual bed leveling several times, even with different spacers (the thickest being a PCB with riduculous 1.6 mm), all yielding the same results. Active bed leveling was activated for each print, which may explain that the manual leveling was effectively without effect. But if this is the case, there surely must be a way of calibrating the z-offset for the active bed leveling, right?

 

Several online searches did not turn up any results, but maybe someone here in the forum can help? Any hint in the right direction is highly appreciated.

 

Thanks,

Andy.

 

Edit: Tested and verified for the second printcore with PVA loaded.

Edited December 16, 2019 by gandy
Additional info

[ahoeben 1,965]

You could try the Z Offset plugin, setting the Z Offset to 0.04 mm.

[gandy 10]

@ahoeben, thank you for the suggestion. I somehow hoped for an actual settings parameter in the printer.

 

I do not really know how active leveling is implemented in the UM S5. Surely, the capacitive sensor in the printhead is used to determine the distance of the printhead from the bed. During each probe, the nozzle not only touches the bed, but the bed is raised a little further still, so much it tilts ever so slightly, barely noticable. I've seen a few videos of other S5s and also UM3s doing the same, so I assume it's part of the probing scheme. That may imply that the firmware checks for which z-height the capacity sensor's signal starts to flatten out. That would be the position where the nozzle makes contact with the bed surface. It would be quite independent from the bed material, too (metal under glass or bare aluminium), as long as there is something the sensor can react to. But it could still leave a certain offset that needs to be corrected.

 

Maybe someone from ultimaker could bring a little light into this, the fact that someone went to the troubles of writing a z offset plugin in the first place indicates that I'm not the only one struggling with the initial layer height. And honestly, I believe this needs to be corrected at the printer level, not the slicer.

[nallath 1,123]

1 hour ago, gandy said:

That may imply that the firmware checks for which z-height the capacity sensor's signal starts to flatten out. That would be the position where the nozzle makes contact with the bed surface. It would be quite independent from the bed material, too (metal under glass or bare aluminium), as long as there is something the sensor can react to. But it could still leave a certain offset that needs to be corrected.

Correct. It moves the nozzle a certain distance and then checks the change in capacity. At some point you will have a "knee point" where a given move doesn't result in an as great value change. We fit 2 lines on this and the intersection is the z distance.

The z offset plugin wasn't written for Ultimaker printers in mind but for printers that don't have auto bed leveling (it was also not written by us, but that doesn't mean it might not be usable for Ultimaker printers of course)

[ahoeben 1,965]

1 hour ago, gandy said:

someone went to the troubles of writing a z offset plugin

 

That would be me. Feel free not to use the plugin, but I think it would solve your problem.

[tinkergnome 927]

On 12/16/2019 at 9:40 AM, gandy said:

the first layer was of a consistent 0.16 mm height instead of the 0.2 mm specified in Cura

 

Active leveling is intended to "squeeze" the material for the first layer on the buildplate a bit (to ensure a better adhesion).

This behavior is normal and calibrating is neither possible nor planned (AFAIK).

BTW: Z-Offset plugin works fine if your requirements are different. 🙂

[gandy 10]

@nallath, thank you for getting in touch and confirming my theory.

 

@ahoeben, I am sure the z-offset plugin does a wonderful job and if the printer does not allow to adjust for the error in initial layer height it is indeed the only way to keep dimensional accuracy. I will definitely give it a try, thank you for your work!

 

@tinkergnome, you're right, squeezing in the first layer is an important factor to improve bed adhesion. That's why most cura profiles default to 120% initial layer line width. Active leveling on the other hand allows the printer to correct for a non-planar printing bed surface, making certain that the distance of the nozzle to the bed surface is the same for all positions of the bed, which is necessary for homogeneous material deposition. The intended result of any kind of bed leveling, be it manual or automated, should not be a false distance, as this really messes up dimensional accuracy.

 

 

[Link 34]

i summary the hight of the first layer, which is set in relation to the heights found during the active level are hard coded by the UM team, they have devised how much squish to apply to the first layer. You can keep adjusting the first layer height but the same amount of squish will be applied. This hard coding of the first later squish was also a issue for me when printing PETG for example where i needed a bit more of a gap. 

 

From day 1 i have used the offset plugin, it solves all the issues. I am assuming you want to get the right 'height' for the first layer, and compensate for the reduced adhesion by increasing the flow in the first layer ?, just add some offset to get the height you want and increase flow to make it stick.

 

it does seem strange UM hard coded this offset as without the plugin printing PETG would be a total nightmare as the nozzle is too close and picks up filament, same thing for metal filaments.

[robinmdh 100]

bed leveling (at least the single probe concept) was explained here:

The probe logs are saved on the printer in:

/var/lib/griffin/probe_reports_*

so if you enable developer mode:

 

That way you could have a look at the raw measurement data.

 

One of the problems is for instance blobs at the end of the nozzle which the leveling then  has to push trough, changing the curve, this and many other unpredictable influences and differences between printers do make this a difficult problem. And like @tinkergnome said it then also influences buildplate adhesion which is very important as well.

As far as I'm aware there is no constant set to change the height.

[gandy 10]

@robinmdh, thank you for the two links, I wished I had known about those a week ago 😀. It's good to see how much information you share on your products, nowadays this is not typical for most businesses.

 

The first article actually confirms my assumptions on how the probing scheme works. I'll check out developer mode and the measurement data later, but do they really contain all measurements while the bed is approaching the bed up until the probing ends (like the curve of the sensor signal vs. z-position shown in the first article) or is it just the raw z-position of the trigger points for each probed x-y-position on the bed, i.e. some sort of topography map?

 

And yes, build plate adhesion is an important issue, but that's not my point. My point is that the first layer height is wrong and the apparently broad user base of the z-offset plugin that served as a workaround shows that there is a systematic issue that users have the need to compensate for. My argument is, that this compensation at user level would not be necessary, if the compensation would already happen at the machine level. I've just learned that this is something being worked on, so for now I'm accepting the use-as-is and looking forward to a future firmware possibly taking care of a perfect initial layer height 😉
 

Edited December 19, 2019 by gandy

[ahoeben 1,965]

1 hour ago, gandy said:

the apparently broad user base of the z-offset plugin that served as a workaround shows that there is a systematic issue that users have the need to compensate for

 

You are - again - assuming that the plugin is only used by S5 users. This is not true.

 

I did not write the plugin to compensate for mis-calibration in the z axis, but to give users of Cura (most of whom don't use Ultimaker printers!) a convenient way to "squish" a print more or less onto the buildplate for better adhesion / removability from the buildplate.

 

This does not mean that the plugin can not be used to solve the issue you mention in your opening point. I don't get why you insist on ruling out a solution, demanding that it is somehow fixed in the printer. But to each its own I guess.

[gandy 10]

@ahoeben, I guess I have understood the motivation behind the plugin and the benefit as a workaround in the case of the S5 perfectly the first time, thank you. Regarding the issue at hand, of course you can choose to not follow my line of argument, but as you say: Each its own.

[robinmdh 100]

8 hours ago, gandy said:

@robinmdh, thank you for the two links, I wished I had known about those a week ago 😀. It's good to see how much information you share on your products, nowadays this is not typical for most businesses.

 

The first article actually confirms my assumptions on how the probing scheme works. I'll check out developer mode and the measurement data later, but do they really contain all measurements while the bed is approaching the bed up until the probing ends (like the curve of the sensor signal vs. z-position shown in the first article) or is it just the raw z-position of the trigger points for each probed x-y-position on the bed, i.e. some sort of topography map?

 

And yes, build plate adhesion is an important issue, but that's not my point. My point is that the first layer height is wrong and the apparently broad user base of the z-offset plugin that served as a workaround shows that there is a systematic issue that users have the need to compensate for. My argument is, that this compensation at user level would not be necessary, if the compensation would already happen at the machine level. I've just learned that this is something being worked on, so for now I'm accepting the use-as-is and looking forward to a future firmware possibly taking care of a perfect initial layer height 😉
 

they contain both.

here's a sample probe point from my printer, there are 2 reset points which have more measurements to determine the approx buildplate location/nozzle difference and the resulting grid as well as the raw sensor data per probe point:

{
                "_ProbePoint__raw_sensor_data": "7.15250 4981 0\n7.15000 4981 2\n7.13000 4978 2\n7.11250 4982 12\n7.09500 4982 9\n7.06500 4988 9\n7.05500 4987 14\n7.03500 4988 6\n7.01500 4992 10\n6.99250 4997 10\n6.97500 4999 10\n6.95500 5001 10\n6.93500 5002 10\n6.91500 5005 10\n6.89500 5004 9\n6.87000 5010 10\n6.85500 5011 14\n6.83500 5013 6\n6.81500 5014 10\n6.79250 5020 10\n6.77500 5018 12\n6.75250 5023 9\n6.73500 5028 10\n6.71500 5027 9\n6.69500 5029 11\n6.67250 5033 9\n6.65500 5036 12\n6.63500 5038 8\n6.60750 5041 11\n6.59500 5041 14\n6.57750 5042 5\n6.55500 5047 10\n6.53750 5050 10\n6.51750 5054 10\n6.49500 5057 10\n6.47500 5061 10\n6.45500 5059 10\n6.43500 5060 10\n6.41000 5064 11\n6.39750 5068 12\n6.37750 5071 6\n6.34750 5075 11\n6.33750 5077 15\n6.31750 5080 4\n6.29750 5084 10\n6.27750 5085 10\n6.25750 5089 11\n6.23750 5093 9\n6.21500 5098 10\n6.19750 5098 12\n6.17750 5099 9\n6.14750 5105 9\n6.13750 5112 15\n6.11750 5110 5\n6.09750 5112 11\n6.07750 5114 9\n6.05750 5121 10\n6.03750 5120 9\n6.01750 5126 10\n5.99750 5129 12\n5.97750 5133 9\n5.95000 5134 10\n5.94000 5139 14\n5.92000 5141 6\n5.89750 5148 10\n5.88000 5148 10\n5.86000 5150 9\n5.84000 5154 11\n5.82000 5158 10\n5.80000 5162 9\n5.78000 5166 10\n5.75500 5168 11\n5.74000 5175 12\n5.72000 5173 7\n5.69000 5178 10\n5.68000 5181 15\n5.66000 5183 5\n5.64000 5182 10\n5.62000 5182 10\n5.60000 5182 10\n5.58000 5184 10\n5.56000 5185 10\n5.54000 5186 11\n5.52000 5187 8\n5.49250 5178 11\n5.48000 5179 14\n5.46000 5181 6\n5.44250 5185 9\n5.42250 5183 11\n5.40250 5188 10\n5.38000 5189 10\n5.36000 5192 10\n5.34000 5189 9\n5.32000 5190 11\n5.29750 5192 10\n5.28000 5193 12\n5.26250 5188 8\n5.23250 5190 10\n5.22250 5196 14\n5.20250 5194 5\n5.18000 5184 10\n5.16250 5183 12\n5.14250 5185 8\n5.12250 5187 10\n5.10000 5180 10\n5.08250 5180 12\n5.06250 5179 8\n5.03500 5181 10\n5.02250 5181 14\n5.00250 5182 6\n4.98250 5185 10\n4.96250 5184 10\n4.94250 5188 10\n4.92250 5191 9\n4.90250 5189 11\n4.88500 5197 10\n4.86250 5203 9\n4.85500 5203 11\n\no6D0F40",
                "_ProbePoint__date_time": 1576776924.1612086,
                "_ProbePoint__bed_temp": 58.79841636258285,
                "_ProbePoint__location": {
                    "_Vector2__x": 106.5,
                    "_Vector2__y": 173.5
                },
                "_ProbePoint__z_offset_from_bed_zero": 5.643527916746965,
                "_ProbePoint__nozzle_temp": 156.9
            },

This is repeated for each point probed. We don't necessarily probe the whole grid though only if something is printed above that section.

while it is still just a raw chunk of text the first value on each line is z the second is the raw sensor reading, the 3rd I don't remember at this moment  (could be the checksum but could also be some internal value ).

 

The main point is well received and understood, but we'll have to do extensive verification on multiple printers before we make a change. Maybe we could make a change to have it configurable in the json config files on the printer in the sorter term but putting this on the UI is just not my decision.

[gandy 10]

@robinmdh, thank you for the detailed information on the probing data. Actually, yesterday after ssh-ing into the machine and just before leaving work, I found the column description in the comments of the relevant python code. I'll probably extract one or two measurement curves out of curiosity, but my original question is answered.

 

To summarize: There currently is no parameter to correct for the observed error in first layer height on the machine level. Due to some DM exchange with @nallath the issue is known and possibly being resolved in the future. Obviously, this may take some while. Currently, there is an existing workaround in form of the z-offset-plugin for Cura.

 

Thanks again to all participants for the discussion,

Cheers,

Andy.

[kbarkes 0]

Just for the sake of feedback to ultimaker, We have had an s5 for about 3 weeks now and I am having the exact same issue. All of the first layers are way too close to the bed no matter what settings I change. Sometimes there's even holes in the first layer when i remove the print. It doesn't usually cause the print to fail but because the printer seems to think its further away than it is it will scrape against the print and dirty up the nozzle very quickly. I'll use the z offset plugin to fix it (thanks @ahoeben) but this issue definitely needs to be addressed by ultimaker. I love the printer and I hope this feedback will help to correct the issue.

[Link 34]

I agree, I was confused when i got my S5 and was really concerned that the offset plugin might not work. In fact I checked the plugin would work before I purchased the S5 as it was key for me. Without it you have no control over the first layer height. @ahoeben is a life saver with that plugin. If that ever stopped working I would see my S5 in a very different light !, best machine by far on the market but it 100% needs that plugin !

[Link 34]

On 12/18/2019 at 1:55 PM, robinmdh said:

bed leveling (at least the single probe concept) was explained here:

The probe logs are saved on the printer in:

/var/lib/griffin/probe_reports_*

so if you enable developer mode:

 

That way you could have a look at the raw measurement data.

 

One of the problems is for instance blobs at the end of the nozzle which the leveling then  has to push trough, changing the curve, this and many other unpredictable influences and differences between printers do make this a difficult problem. And like @tinkergnome said it then also influences buildplate adhesion which is very important as well.

As far as I'm aware there is no constant set to change the height.

Interesting, so from what you say here the aim is to actually achieve the first layer gap as set in Cura but inaccuracies result in the reduced height from the specified?, and if things worked exactly as designed the first layer would be as set in Cura and to get adhesion better more flow would be required, for example to 120% ?, I assumed a squish was added in as a number to reduce the layer height by but thats not the case ?

 

Thanks 

[robinmdh 100]

Both yes and no. Cura already overextrudes a bit to create a squishy first layer so extra squis is intended. But any error in height is unintended.

 

There are many tiny errors that all add up, we are trying to understand where they all come from so it's likely we will make an update in the future to iliminate this as well as the one caused by temperature differences in the printcore. It will take quite a while though...

[vtjballeng 0]

I can say that, for my part, no z axis height adjustment on the machine is an absolute deal breaker. I was about to buy an S3 for my company and stopped when finding this out. 

 

Live Z is an extremely useful and helpful feature on our Prusa Machines that save us time, effort, & money.

[gr5 2,205]

I had this feature on my UMO and it's nice but I don't miss it because unlike the prusa, the bed moves up and down on the Ultimaker printers and so it starts all the way up.  so it's very convenient to reach under the build plate and be able to turn the 3 leveling screws.  You can turn them live while it prints.  The 3 screws are built so well that it's trivial to adjust them while the printer is printing.  Smooth, easy action.  It's a very simple, quick process.  Similar to "live z".

 

I do this all the time on my UM3 and UM2 printers but it's not needed on the S3 and S5 because their autolevel works extremely well.  But you can do it if you want.

[marine3D 6]

On 4/23/2021 at 1:34 PM, gr5 said:

I do this all the time on my UM3 and UM2 printers but it's not needed on the S3 and S5 because their autolevel works extremely well.  But you can do it if you want.

Out of curiosity, how does the auto levelling on the S3/5 differ from the UM3? Slightly better sensor board or different levelling process?

[nallath 1,123]

10 hours ago, marine3D said:

Out of curiosity, how does the auto levelling on the S3/5 differ from the UM3? Slightly better sensor board or different levelling process?

Different software. The S-line can level in a grid and compensate for that. The UM3 only does it on 3 points.

[gr5 2,205]

The UM3 levels 3 axis (tip, tilt, height).

 

the S3/S5 also detects "hills" and "valleys" in the glass and corrects for these as well: grid compensation.

 

The sensor is the same.  But you can't disable autoleveling on the S3/S5 (well you can but it's a pretty serious hack) but you can disable it on the UM3.