Beacon probe Z-offset is consistently too far from build plate
I've ran into this issue while installing and recommissioning my 500 V-core 3.0 with a new Toolhead V1.0 assembly. Every print starts the first layer too fat from the build surface (textured PEI sheet). I will baby step the print in to a good layer height and save it with "SAVE_Z_OFFSET" via console as per the RatRig Beacon documentation. I'll get a confirmation in console of the new thermal expansion compensation multiplier being saved, and entering SAVE_CONFIG once the print is done. I have no idea if the response I am getting of "The new multiplier value has been saved to the configuration" is correct or not. It doesn't exactly sounds like the correct response for a manual Z offset adjustment
On the very next print the first layer will be nearly exactly as where it started on the first print pre-baby stepping. It's as if RatOS is overwritting the old Z-offset at the start of each print. My current understanding is that manually entered adjustments should be saved. I should note that at the start of each print I get a very consistent "Nozzle expansion offset" of -0.043281mm just before the printer starts printing, regarldess if I babystepped the previous print or not.
What I would like help with is:
-Where and what should I be looking for to verify if RatOS is overwriting these manual adjustment values
-Is there a more correct way of saving the baby step offsets
Thanks!
30 Replies
I've made some interesting finds after some ad hoc testing tonight. It appears that the variable controlling z-offset for the beacon model is "model_offset =" under [beacon model] and using SAVE_Z_OFFSET as stated by the RatOS docs is incorrect and doesnt update the beacon model offset. The correct command to use is Z_OFFSET_APPLY_PROBE as stated in the docs from Beacon3d. Coincidentally, this is what the "SAVE" button does in the toolhead babystepping window, the button the RatOS docs specifically tell you not to use for Beacon. My guess is that those docs were written in a time when the Beacon integration wasn't fully complete and then not updated later? Don't know, maybe someone else can confirm my findings.
Next discovery was with the values that were saved using "Z_OFFSET_APPLY_PROBE". I had to adjust the nozzle to be about 0.100mm closer to the print bed to get a good first layer. This resulted in a model_offset of 0.100 being saved. Started the next print and the nozzle was even further away than before. Stopped the print and on a whim manually set the model_offset to -0.1mm. This brought the nozzle to nearly the same spot I had it on the print prior. Made a few babysteps to get back to perfect which was another 0.03mm closer to the print bed. Used Z_OFFSET_APPLY_PROBE to save the value and restarted the printer. Except now the model_offset was set to 0.0300mm. It looks like I may have found a bug. Of course this resulted in a first layer too far from the print bed. So I stopped that print, went in and manually set model_offset to -0.130mm and started a new print. The first layer was perfect.
So:
-It appears the correct command to save beacon offset values is Z_OFFSET_APPLY_PROBE BUT any values saved using this method will be in the incorrect sign
-Using babysteps to dial in the nozzle a second time after setting model_offset will result in that value being overwritten with the sum of your current print's microsteps adjustments
This has me thinking now, if a basic error like this exist for simple adjustments, could there be the same mistake in regards to the nozzle thermal expansion compensation or one of the other calibrations the RatOS macros handles for us? I think my next step is to do a few more first layer pritns to really quantify any variance in repeatability of the first layer offset accuracy and then create a beacon model using the procedure outlined on the Beacon3d offical docs to see if I get different results
I'm interested to see what you find. I have been fighting a bit with Idex z-offset applying an offset way to high for the T1 despite the idex_z_offset being tiny
@miklschmidt
Read also into this if you do print with larger first layers times you also need to have the gantry expansion in mind https://discord.com/channels/582187371529764864/1360247935496884265
Yeah, I've been soaking extensively and the layer is consistent thankfully
Will be buying a Ti tube when there are some in stock
i think they are back in stock now
Thank you for the heads up. Toro said later, but I guess they came in early
I will read through this thread. Right now all of my first layer test prints have been ~5 minutes. Once I start getting consistent results at the start of a print ill bump it up to plate size first layers to see where im at.
Further testing notes from today:
My problem now is variance in first layer hieght now that I've been setting model_offset. Recreating a beacon model from scratch using the Beacon3d docs yielded very similar results to RatOS's calibration. The variance I am experiencing now is enough to take a dialed in first layer to over-squish ribboning or visible gaps in lines in subsequent prints.
I set variable_beacon_contact_expansion_compensation to False to see if this was causing any additional variances. This did not seem to have any noticeable impact on layer consistency.
I did notice on my lasty few test prints today that the Z-offset in the toolhead window is being set to strange values during the start print process. Sometimes its 0.0, sometimes its 0.3, other times its somewhere in-between. But none of these values are the model_offset value. I have no idea where or how this number is being calculated, maybe in the auto-contact calibration does in the pre-print process. But I believe this to be the leading cause of my variance issues now. The large variance in this number, typically +/- 0.15mm, is about the amount I need to correct back to a good layer height.
I am going to order a SuperPINDA and compare results when that comes in to see if I have something else going on or if is Beacon related
You're confusing multiple thing. There's a few layers on top of the beacon code in RatOS. You need to use SAVE_Z_OFFSET, since RatOS adds nozzle expansion compensation on top. Klipper has no way to specify multiple offsets, it's all done with a single runtime variable, and thus if you want to save the z offset to the model, RatOS has to subtract the nozzle expansion compensation layer first or it would accumulate as your z offset over time. Follow the RatOS documentation.
That said, model offset is absolutely useless if you use true zero.
As in, it doesn't do anything. The model offset is for proximity scans not contact.
All of this is changing in the next release btw, because people keep being confused (for good reason).
There are huge variations caused by mechanical changes btw, don't trust your measurements unless you've isolated all of the 5+ factors involved here.
Rat-OS 3.0!
Yeah, I can understand why.
I posted about it in the Idex chat, but I'm having issues getting my T1 offset to be correct. I followed the instructions on the docs website, but my T1 offset is too large. Here are the steps I did.
Calibrated idex_z_offset using VAOC
Calibrated thermal expansion using VAOC
Soaked bed for 1hr with X axis in center of bed
Began a print for a single layer with T0, slowly stepping to find that 0.050 is the best
After the print was finished, the z-offset values were reset, so I moved it to 0.050 again
Used the command "SAVE_Z_OFFSET" as stated in the docs
After this process I did a test print with T1. Soaked for an hour, single layer print. Whatever math it does it came out to 0.092, and the print that comes out is clearly too far from the bed. Is there something I have missed?
Yes, you need to run SAVE_Z_OFFSET after you've finetuned for the first layer as it's dependent on nozzle temperature.
But T1 offset has nothing to do with beacon.
that's relative to T0 and is found via a button. If you have problems with that it's mechanical (ie loose nozzle / hotend etc)
I am certain that my nozzle and hotend are not loose. I have redone the idex z offset multiple times after making absolutely certain both nozzles are clean and nothing changes.
Even this can result is heat expansion on the gantry
I got my super pinda probe hooked up about two weeks ago and my prints have had a near perfect first layers every print now. I think it's safe to say there is definitely something going on with the either the beacon probe itself or the RatOS macros soing something strange
I have the same setup as you, and really 1to1 the same problems with the first layer.
Makes me wonder if I shouldn't switch to the super pinda, because of the bad first layer I just don't use the printer. too bad about the 3000€ in total.
I strongly suspect something is wrong with how the beacon is being used
I am now 100% certain, something is absolutely wrong with how Z offset is done.
A few days ago I replaced the heater on the bottom of my bed. As such I knew that I would have to modify my z-offset, as I had moved the bed.
I go through step 6 here: https://os.ratrig.com/docs/configuration/beacon_contact/
Original was 0.127. I step down over the progress of the print, find that -0.303 was now correct.
Once the print finished the little window with the z-offset gets reset. I moved it down to -0.300 (the closest I can get). I then typed
save_z_offset into the console and saved the config.
After restarting I went to do another test print. When starting the print, the z-offset was set to the original 0.127! I quickly began stepping down, but the nozzle was now in the plate (saved it before any actual problems). It displayed 0.127, even though I had changed it. Clearly the printer was acting differently despite displaying the same number.
I then started a third print as specified in the steps. Starting from "0.127" I started to step down, finding the optimal point to be -0.053. Instead of setting the z offset again I simply hit the "save config" button and started up another print. As expected, this print also needed to be offset to -0.053 manually.
save_z_offset does not work in the way that it is supposed to. Whatever it is doing, it is not just saving the value in the z-offset section of the toolhead in ratosBeacon Contact | RatOS
- Prerequisites
exactly the same thing i figured out.
i also found out that the multiplicator in the beacon changes something with the z offset. whenever i set it to 1 then make a print, then baystep the height and use save z offset everything fits! the offset is also kept well in the 1st print, the compensation works, the first layer then looks good. but during the "save_z_offset" command it writes a multiplicator in the files. the next print is then NOT my set z offset and the compensation based on the beacon model in the heightmap does not work at all.
we seem to be doing something wrong or misunderstanding something. we can't be the only ones with the error, i've looked through the support threads, there are a few more people who have problems getting the first layer to be constant.
my heightmap looks really good when the printer is tempsoaked. no gantry twist, nothing. everything is great. but it's messing something up... or I'm just too stupid.
Yep, everything else about my printer is also really well built. I didn’t want to need to, but I think I need to dive deep into the bowels of RatOS to figure out exactly what the fuck is going on
@miklschmidt maybe you can give some directions here?
Yeah, any directions as to where to look would be appreciated. Once I know where to actually look I'm sure I should be able to eventually figure it out.
i have even worse problem after changing nozzles and running automatic calibration, after that i did just BEACON_CALIBRATE_NOZZLE_TEMP_OFFSET with 0.096562, i don’t know how it can set offset of 0.594885 at 225°C
before changing nozzle it was of by that 0.1mm usually
Finally got around to digging, here is what I have found so far.
The
SAVE_Z_OFFSET function is saved within RatOS/macros/util.cfg. If you have a beacon (which we do) it calls _BEACON_SAVE_MULTIPLIER
This function, _BEACON_SAVE_MULTIPLIER, is saved within RatOS/z-probe/beacon.cfg.
Frankly I am not good at reading this type of code, the language is fairly foreign. From what I can gather, it will read some values, the important one being runtime_multiplier. I am unsure as to when this is set, but it seems to be related to the microsteps you have set.
If the multiplier is positive, it saves the multiplier to nozzle_expansion_coefficient_multiplier.
If the multiplier is negative, it runs the function Z_OFFSET_APPLY_PROBE
Something feels wrong with that, because it means there are two different paths for when you are stepping down the z-offset and when you are stepping it up.
From what I can gather, Z_OFFSET_APPLY_PROBE is an overridden version of a base klipper command. I can't find it. I can find it on the RatOS Git, but not the version that is running on my printer. The output I am getting from it is notably different.
I did find a PR from early March on the git that seemes related to z-offsets, but isn't directly about them. Something about streamlineing the way they work
The fact that it is applying differently if the move is negative entirely explains why things are not working as expected for my recent adjustments
The best solution to my problem is likely finding a way to entirely reset the values back to uncalibrated
What values I am not sure, which is part of the problemI agree the embedded macros are very difficult to follow. But I think maybe the multiplier should always be a positive number? If it's being handled like a coefficient where 1.0 is a no-difference value, then anything less than 1 would result in a smaller value, and a value of 0.0 would zero out any value that's there which im assuming we wouldn't want.
what i found out in the process of trying it out is that the beacon multiplier reset to 1 means that the Z offset really corresponds to the set offset, based on the measured beacon model that you should have done beforehand.
the first print with the multiplier set to 1 is really great.
it compensates perfectly for the tolerances of the bed. even if you adjust with babysteps.
But if you then use the SAVE_Z_OFFSET command, it writes totally inexplicable values to the beacon multiplier, and accordingly the z offset from the heightmap(beacon model) is added to the beacon multiplier in the next print.
i hope you understand.
Assuming the multiplier is set to 1 -> I print the first print.
the set z offset with the babysteps shows e.g. 0,200mm.
Then you execute the command save_z_offset, and it saves a multiplier of e.g. 2.
During this time, the complete first print, the first first layer, works perfectly.
In the next print, it uses the distance that the beacon sensor measures (from the heightmap) and also the multiplier and thus arrives at, for example, a completely different z offset than previously set.
and because the distance in the beacon model always fluctuates, e.g. 0.2 then 0.1 then 0.3, the multiplier is amplified far too much and I can't get a reasonable first layer.
I have been having the same issue. I have found the best results by never calibrating Z offset when using both extruders in a print. And I only calibrate z offset for T0 never T1. Doing this seems to work better. But there are definitely issues in the code and the method used to store Z offset is not clear at all. For example, why does the save z offset command have to be typed and why does the macro of the same name disappear during a print? Seems silly. Also I think it's a terrible idea to alter the thermal expansion coefficient multiplier as a means to alter the z offset at runtime. I feel like it's a much better idea to just save a static variance to the z offset in the beacon model. Altering the thermal coefficient multiplier assumes that changes are linear, and they almost certainly are not.
I've tried using contact for creating adaptive bed meshes before each print and this seems to have helped a little. I did notice a very small amount pf filament oozing from the nozzle at around 150C so I created a simple wipe macro that runs in _USER_START_PRINT_AFTER_HEATING_BED. For the wiping I placed a bambu lab style silicon pad on one side of the print bed the nozzle lowers itself onto and runs back and forth a few times. Nothing fancy.
This has yielded me by far the best results so far. Ive been running the same first layer test print which is a 4x25cm strip at a 45 degree angle across the bed. This makes the first layer infill perpendicular to the long side of the test strip. Ive laid it across the center of the bed that has the worst of the warp to it for testing the bed mesh. Out of 5 prints I've done so far, the first 3 were near identical-perfect. The 4th was slightly to close with minor ribboning and the 5th was too far away with gaps between lines.
I've read on the Prusa forums of people having issues with first layer height because of the nozzles oozing during the contact probing. They lowered their nozzle temps from 170C to 140C which helped. My only concern with lowering the nozzle temps even further would be that the nozzle wiping would become less effective. Perhaps if I started the wipe at say 200C and let it lower to 140C by the end it would be the best of both?
One last side note. While doing BEACON_RATOS_CALIBRATE, or other sample collecting involving multiple contact probes in the same spot, I've seen quite a few "samples exceed tolerance, retrying" warnings. It never fails a calibration, but it does take a few tries sometimes before moving on. Not sure if this is a common occurrence with contact probing or a symptom of filament oozing from the nozzle during the process.
I find if I have a lot of retries it's due to oozing or debris on the nozzle. (in my case).