RatOS 2.x + Beacon ignoring configured offset and discarding offset at print end
I believe I've accurately followed the steps outlined here:
https://github.com/HelgeKeck/RatOS/blob/documentation_v2.1/site/docs/configuration/beacon_contact.md#6-first-print-and-fine-tuning
I've printed a simple single layer print, baby stepped the offset, and then executed
SAVE_Z_OFFSET.
Doing so resulted in the following output on the console:
Which is, in fact, reflected in my printer.cfg:
However, when a print starts, I see:
And sure enough, the first layer doesn't squish/adhere very well. Furthermore, if I babystep back to my above value, things look good. Until the next print.
An additional item of note is that it appears any babystepped value is cleared at the end of the print. So, it seems, one must execute SAVE_Z_OFFSET during the print.GitHub
RatOS/site/docs/configuration/beacon_contact.md at documentation_v2...
The preconfigured Raspberry Pi image that makes it easy to run Klipper + Moonraker + Mainsail on your printer. - HelgeKeck/RatOS
187 Replies
Beacon model offset has been updated, new value is -0.00524 You must run the SAVE_CONFIG command now to update the printer config file and restart the printer.if you get this resposne it means it didnt updated the thermal expansion multiplier, isntead it created a offset in the beacon you are using two different methods that fight against each other run
`SAVE_Z_OFFSET during printing then it works as expectedthey are definitely fighting with each other, that's for sure
its also normal that it resets the offset after a print has finsihed
no that's what I did
do you have the thermal expansion activated?
printer was printing, don't know how to activate or deactivate thermal expansion
also,
SAVE_Z_OFFSET needs to be run in the console, do not print any button in the toolehad control for it
otherwise you run a different command
but you need to know if oyu have enabled it at a point?I issued it via the console
and made the calibration
based on the console output during the print, it seems to be active
2:45 PM
RatOS | BEACON: Nozzle expansion offset of 0.044757mm applied to T0
I adjust the offset immediately after, and issue
SAVE_Z_OFFSET, and get the output I provided
I can do it again in this log session if you'd likeso the only reasonm why ratos can fall back to the original apply z offset macro is when you either have thermal expansion deactivated or if you have a negative thermal expansion offset
if you have a negative offset, which is physically impossible, then this points to a loos hotend or nozzle during the thermal expansion calibration
my desired offset is negative from the applied one
i highly recommend to recalibrate tit, there is something off
negativ can not be, this means oyur hotend is contracting when it gets hotter
im pretty sure during your calibration some z offset issues where present
its the only logoical explanation
so i would check the nozzle the hotend and all the screws on the toolhead
and then recalibrate it
the hotend is rock solid, push/pull and the entire printer moves
still, if oyu want to have a negative offset, then something is off your setuip
its jsut no posible that the hotend wants less offset after you are heating it up
redo the calibration please
make sure to remove any other beacon z offset that might be there in your config
I understand what you're saying, but also know what I'm seeing... they don't agree
i have seen this issue already multiple times, it had always the same root cause
you have no other choice than to redo the calibration and then to check if you still wnat a negative value
if this is the case this points to some sort of z-issues
redo the entire calibration or just the thermal expansion bit?
no matter from where they get induced
jsut the thermal thing
heating and cleaning the hotend to ensure no drippage
hotend must be empty
that's part of cleaning it
removing commented offset from
printer.cfg
but leaving other values
running BEACON_CALIBRATE_NOZZLE_TEMP_OFFSET
check that, have to wait for nozzle to reach ambient first
going to call current temps ambient
No trigger on contact after full movement
have to start over
Probe samples exceed sample_tolerance
yayi rest my case, you have some repeatability issues
I lowered the amps on my z motors, but seems I need to keep them higher. Will see once the calibration is finished
No trigger on contact after full movement
I'm at a loss at this point
will redo the entire beacon calibration
removing every bit of saved information under (and including)
[beacon model default]
Ran BEACON_INITIAL_CALIBRATION followed by SAVE_CONFIG
Running BEACON_POKE_TEST
running BEACON_CALIBRATE_NOZZLE_TEMP_OFFSET
Once it reaches the 250C test samples just keep exceeding tolerance
only give of any kind I can find is the linear rail carriage itself
found a culprit... some filament left
that seems to have been it, no retries on this run so far
yep, no retries on that run
T0 expansion coefficient 0.050937, higher than the original
Ran the BEACON_FINAL_CALIBRATION BED_TEMP=60 calibration
now on to a first layer trial and adjustment
This seems to have worked, but still needed to step the offset to a near negative value to get the desired first layer 0.006
Testing an untouched reprint of the model nowz-offsets can be negative
but the expansion multiplier not
reprint's first layer looks nothing like the adjusted first print
looks like someone threaded a loom
Adjusted first layer
Untouched reprint
Does it matter that my printing temp is higher than the highest temp used during the calibration?
yes, but should be negligible
this looks like a combination of extrusion issues and too high Z. Are you printing with a 0.6 and forgot to put it in the slicer by chance?
nope 0.4
and BTW, saving z offset after print does NOT work:
I assure you I made a change
and attempting to replicate it after printing:
not doing z offset after print, doing z offsets while printing, after print is finsihed you canonly save the previoulsy add offset
you cant zhop up or down and then save it all after the print
Look at the screenshot, the offset was changed while it was printing
attempting to save after the print failed
it's all in the screenshot
looking through the code...
if it matters, the baby stepping was done from mobileraker
going to redo it from mainsail
well, printing at 270 vs the calibrated 250, other materials will be MUCH higher, 100C+ higher
@JaminCollins if you slicer is not set up to correctly report layer numbers the offset stuff won't work
And there's no warning (adding one)
What profile and slicer are you using?
this isn't it
been there, done that
IT's in the "on layer change" custom gcode
that's what the warning pointed to
Sorry i might be out of the loop, what warning?
Check the
after layer change gcode here: https://github.com/HelgeKeck/RatOS/blob/documentation_v2.1/site/docs/slicers.mdGitHub
RatOS/site/docs/slicers.md at documentation_v2.1 · HelgeKeck/RatOS
The preconfigured Raspberry Pi image that makes it easy to run Klipper + Moonraker + Mainsail on your printer. - HelgeKeck/RatOS
This is all part of the default RR profiles
That's not it
it's looking for
TOTAL_LAYER_COUNTyeah different variable, different warning 🙂
Not used for zoffset either
Please see the doc i linked
so, I should be getting some sort of warning on print start?
Or use the official RR profiles
No
That's what i'm saying, there's no warning about this
Which is a problem
I'm adding one
ok, added all of them
@Helge Keck i must be blind, but i can't find anything linking
SET_GCODE_OFFSET to _BEACON_APPLY_RUNTIME_MULTIPLIERbut this is a single layer object
doesn't matter
You still need it
resending the resliced object
it defaults to 0 and checks for 1..
lol my name is even on it, what file is this in? :kekw:
was your stupid idea
:kekw:
omfg i found it
it's in overrides.cfg
Okay good
It's just the layer change gcode that was missing from his profile then
Will add a warning about that
yeah, we need a warning for that
on it 👍
If you have time for another oddity, while the printer is preparing for the reprint...
z-tilt appears to use odd coordinates by default
I can report that seperately if you'd like
ok, set the z_offset, running save while printing
V-Core 3?
v-core 3.1
yeah you need to adjust those manually when deviating from the stock setup. Same with bed_mesh and possibly printer limits.
and we are back to the original issue
No way to automate yet
Can i see your slicer config for the after layer change gcode?
Which slicer is this?
Orca
I wonder if it shouldn't have the +1
Can i see the .gcode?
and even with that adjustment the layer looked like the loom one
we'll deal with that after the z-offset saving issue
It's calling it correctly... Will add some debugging info to figure out what's going on.
double checked, all components are up to date (just FYI)
forcing a recheck shows a few updates
* KlipperScreen
* moonraker-obico
* ratos-configurator
* 15 system packages
Don't think any are related, but happy to force the update
Need to step away for a short bit to feed dogs
you should always run the check, it's only refreshed automatically once a month.
It's not "forcing" anything
You prolly want the ratos-configurator updates though
ratos-configurator updated
Gotta reboot to commit the code, having yubikey problems.
brb
You forced recheck by clicking on the circle arrow on machine tab right?
yes
Okay I just did that although I think mine is update to date, because I did a new rpi os setup to see if that was causing my issues
everything is up to date now
Jamin, you pass the calibration process right?
I think the first time I did step #5, but not this time
Interesting 3 new packages... from yesterday
Fixed the oddball
z_tilt locationsyours were wrong?
I've got a v-core 3.1, I believe the config had them set for a left side mounted pinda or similar
I used to have a 3.1 that was an interesting setup
I got rid of the pinda and put a euclid
they aren't odd when using stock hardware 🙂
yes, stock hardware (superpinda)
I know, I know
not saying you got it wrong, just that I fixed it for my setup
I truly appreciate what you do, and believe I've said so more than once
Since that layer change macro is needed, when I did my first change to
z_offset I'm guessing that it would have calculated the thermal expansion value incorrectly, right?Jamin did you fix yours?
no, we are working on it
testing that i didn't make any syntax errors, couple mins and it should be ready
@JaminCollins RatOS ready to update
queuing the recheck and will update it
Before starting the next print, run
ENABLE_DEBUG
Or at least run ENABLE_DEBUG before hitting the z offset buttons 🙂I can add it to the gcode 🙂
Sure, that'll work.
You'll have to update again, found a mistake 😂
ENABLE_DEBUG is the first thing it does before exclude objectsit'll barf out all sorts of stuff now, just fyi
and made sure I was editing the right file with the layer change update
pulling RC2-104
ready?
print started
and I see DEBUG output
Aight look for the
_BEACON_APPLY_RUNTIME_MULTIPLIER debug message
(should be printed when you hit z-offset buttons)waiting for it to actually start the print and apply its own offset first
it'll be queued to run after anyway, so yeah
start print is a long effin process
yea, just force of habit at this point
Good habit, because else you'll be hitting that button asking why nothing's happening only to get a bunch of z_offset added at the start of the print.
almost there
he says as the nozzle is heating... 😮💨
Z-Offset: 0.011
pausing print so we will still be printing if we want to try to save this offset
I'm guessing this is the problem part:
old_multiplier: 0.18761267932967918, new_multiplier: -0.6303832307624666ok, you have 2 possibilities now
1. turn off thermal expansion comepnsation and work with classic z-offset
2. try to find the root cause for that negative multipler
but I did 1 successful
SAVE_Z_OFFSET since the most recent BEACON_CALIBRATE_NOZZLE_TEMP_OFFSET. I'm wondering if not having the layer change setting messed up the calculated multipliermy guess is hardware issues
and the print at that time, looked good, the subsequent prints did not
when I ensure the hotend is fully empty I get zero retries on the temp calibration
the errors I had here were that it had just enough left in it to mess things up
I can go back through it one more time
but if I can make it through the entire temp calibration with no retries, how do I have hardware issues or repeatablity issues?
@JaminCollins is your bed heated when you're doing the hotend temp compensation calibration?
ie is the enclosure heating up
unit is not currently enclosed
Well... nevermind then 😂
the bed is not heated, the step says to start with ambient temps
yeah exactly, just wanted to make sure
happy to go back through it one more time
since you're running things manually
and not using the actual one-step macro
Collected 3 samples, 0.0005 sd
lines like that make me question the hardware issue
I'd try using the official BEACON_RATOS_CALIBRATE in that case
I've done both the one shot and the manual
yeah, but found filament in the process, right?
not on my first config no
It's just that with the one shot macro, there's no possible gotcha's
but first config had this problem too
happy to try what ever you'd like
got docs for the BEACON_RATOS_CALIBRATE?
beacon docs
linked in the description of #beacon-contact
GitHub
RatOS/site/docs/configuration/beacon_contact.md at documentation_v2...
The preconfigured Raspberry Pi image that makes it easy to run Klipper + Moonraker + Mainsail on your printer. - HelgeKeck/RatOS
this one, right?
si
so purge all configuration details for beacon, then run that with the bed value and no chamber since not enclosed
kk... emptying filament, ensuring nozzle is empty, letting everything cool back down, and firing it off again
yep
should have the configurator rerender the ratos-variables.cfg as well just to ensure a clean slate
what do I need to do, in order to do that?
actually, got the defaults:
You can just save those manually
no idea why mine has idex values, should I leave them or nuke them?
leave them, they're just defaults
super heated the nozzle to ensure nothing is left in it
beacon values removed from
printer.cfg, variables defaults saved
firmware restart, and starting the beacon config, once things cool down
you want debug back on or just go through the configuration?doesn't hurt to turn it on, just in case
I don't actually think there are any debug messages in that process, but if there is, they'll be printed 😄
We're about to find out
waiting for extruder to get back to sub 40C
ok, here we go
latency=2 through so far, heating to 150C
moving on to 250C
so far so good
moving back to 150C
no retries on any probing so far
first 150C, Result is z=0.052187
first 250C, Result is z=0.112500
moving back to 250C
second 150C, Result is z=0.054687
second 250C, Result is z=0.110312
I believe it's on to step #4 now
no retries throughout, thus far
latency 2 on current pokes
possibly on to step #5?
it's probing around the bed
calibration completed
Beacon poke test result:
Average latency: 2.00
Excellent performance for a typical printer
T0 expansion coefficient 0.055625
Gantry twist relative to the center
Very low gantry twist: 32.111553μm.
No beacon scan compensation needed.
Front left: -7.731122μm
Front center: -22.302433μm
Front right: -21.276609μm
Left center: 16.449132μm
Right center: 7.265514μm
Back left: 32.111553μm
Back center: 26.475461μm
Back right: 20.287185μm
What would you like me to do next?
BTW, saving the current variables as a backup
Here's the log through that calibration run
Should I print the first layer?
All of that seems to be great.
Try printing?
will do
reprinting the debug enabled first layer gcode
btw what material are you using since you're running 270C?
you won't believe me when I say PLA
That's some very cooked PLA 😅
but it's not... that's the super odd part
it's the weirdest stuff
Uhm.. You sure your thermistor is reporting correct temps?
Would explain a lot 😂
Tangled
Shop | Tangled 3D Printer Filament
3D Printer Filament that is affordable, made in the USA and actually used by the people that make it.
ah it's some "special" stuff
already went down this road... independently verified it with both a screw in thermistor and a laser hand held
trying to find it's top flow is why I moved from a Rapido to a Dragon UHF
it's happy over 300C
that's toxic af if it's anything like real PLA
any reason baby stepping from mobileraker would be an issue?
No
k, just making sure
it's the easiest way for me to baby step things
as long as it's calling SET_GCODE_OFFSET like everything else, should be fine
also halving the printers speed so there's more time to babystep
🤦
need to load filament again
I gotta go, friday night is gone 😂
03:23AM
sorry, thanks for hanging
Hope you figure out what's going on. Hopefully it's just all unicorns and rainbows from here.
one can hope, but ...
restarting the first layer print
Adjusted and saved first layer looks acceptable
Now for a straight, reprint
So far so good
TL;DR - Not a hardware issue, but rather appears to have been a software issue. Specifically, the lack of the
AFTER_LAYER_CHANGE macro settings in Orca Slicer.
Not having this defined seems (happy to be corrected) to have altered how the nozzle_expansion_coefficient_multiplier is/was calculated resulting in the wrong value being saved. This being retrieved on later prints led to an incorrect offset that only got compounded with repeat attempts to correct it. Eventually driving this value negative which is an impossible value.Jamin did you get it working?
Looks like it..
So far, but not sure I care for the thermal expansion stuff
maybe once I have a way to ensure the nozzle tip is clean, but for now too much variance due to the slightest bit of left over filament on the tip
Im unable to pass.. everthing is fine.. does the initial tests.. then at the end my sample sizes go to hell... and my latencies which were 1-3 at the start/middle all of a sudden are 4-6 at the end
sounds like you do have a different problem, and if the latencies aren't holding, it likely is some flexure in your toolhead
I think it's a lot more useful at "normal" printing temps. It seems that it is very much not linear 😄
(which makes sense as it appears to be the hotend accounting for most of the expansion, and we're measuring the temp of the nozzle)
I've disabled it for now, until I can ensure a clean nozzle at probe time
What effect does the turning off of the thermal expansion? Does it let you adjust z?
Yep.
Interesting.. I got mine to pass calibration.. but my print quality is not very good..
but my print quality is not very good..Well that's not a beacon issue 🙂
@Jamin Collins [VC 3.1 400mm] I have exactly the same issue. I read this post and see a lot of similarities. I have made my printer.cfg anow, removed inlusions of custom stuff, reverted back to an older RatOS version, etc, etc. I am also at the point of kicking the machine out of the door and by a Bambu machine. I tried to log my efforts here: https://discord.com/channels/582187371529764864/1292556582336335904. Can you identify the the actual moment that your z-height was saved? i.e. What did you do to sort that out? Helge suggested that I was not using the Temperature compensations (it is set to TRUE if I do a RATOS echo of the variables) and Mikkel suggested to remove all non essential macro stuff. I don't want to tag them in each and every topic (those guys are doing enough, already) but I also would like to finish my printing project and that requires a working printer,... Any pointers are appreciated
I lastly removed the beacon model from my printer.cfg and set the variables in ratos-variables.cfg to default as per above suggestion. I did an initial beacon calibration, poque-test and at the temperature-compensation test,. it failed so I kicked the dog, took out a football for a walk and went to work (4 hours late...). I think you can relate to those feelings 😉
My printer (and sanity) was saved by removing RatOS 2.1 from the printer and taking everything into my own hands. This was done before (and I believe somewhat led to) the fairly recent rework of z-offset handling. For now, I've gone back to purely probing offsets. I had some holiday prints that needed to be finished. I do plan to revisit touch probing on my own in a week or two.
https://discord.com/channels/582187371529764864/859890291591217162/1289702051277963325
Happy to assist you in migrating to native Mainsail if you'd like.
Haha,... not realy "there yet" with kicking out RatOS as it has some nice features I would like to keep using... Keep you posted
(I might have accidentally solved my issue,... to tired now for further testing but first result are that the nozzle is actually in the neighboorhood of the bed!!! See my thread https://discord.com/channels/582187371529764864/1292556582336335904 if your curious)