Klipper install dirty after update of ratos and klipper
I updated everything a few hours ago and now i noticed that my raspberry pi is running "Host(aarch64, 64bit)
Version: v0.11.0-200-g7511151a-dirty "
Is there anything i can do to get rid of the "dirty"?
+ My bed mesh went from 0.054mm to 0.161mm but i am not 100% sure if this is related since i always used PAM and recently "upgraded" to a cnc milled x-axis. Not sure if it was a real upgrade..
+ Adaptive mesh of ratos seems to have some trouble to make a prime blob and always pulls the blob in the printing are... right after the update i had to lower my z-offset by about 0.17mm to get the first layer correct again
54 Replies
what does the update manager section look like?
Yeah can confirm I had the same happen to me when I re-installed everything for the CB1. Install was dirty straight away. Doesn’t seem to be a problem so far
Everything fine. No problems. Klipper shows the same version but without the "dirty"
did a fresh install. As soon as i upgrade klipper, it shows this version..
fascinating-indigo•14mo ago
had exactly the same, started on a spare PI with RatOS from scratch to check, as you told newest image and you update Klipper --> dirty. happy not alone and I don't need to ask anymore... 😉
The prime blob was made about 3mm up in the air.. that's the reason why it is next to the print
Anyone with a reportedly dirty klipper installation, please paste the output of the following:
fascinating-indigo•14mo ago
hy, below my output of the command. nothing fancy on the install, also the "test-pi" just blank and after the update "dirty". but as I can tell until now nothing not working what I can see, but still rewiring at the moment so may some special features like them below could be affected. OS is 64bit on pi4 and cm4 with emmc, not tested on cb1.
let me know if you need anything more.
pi@CM4-RATOS:~ $ cd ~/klipper
pi@CM4-RATOS:~/klipper $ git status
On branch master
Your branch is up to date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
klippy/extras/beacon.py
klippy/extras/gcode_shell_command.py
klippy/extras/linear_movement_vibrations.py
klippy/extras/ratos_homing.py
nothing added to commit but untracked files present (use "git add" to track)
Yeah there's nothing "dirty" here.. Can you post moonraker.log as well? Maybe moonraker changed it's reporting or something.
Also does it say dirty in the update manager, or only the version reported by the mcu?
On branch master
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
Untracked files:
(use "git add <file>..." to include in what will be committed)
klippy/extras/gcode_shell_command.py
klippy/extras/linear_movement_vibrations.py
klippy/extras/pam.py
klippy/extras/ratos_homing.py
nothing added to commit but untracked files present (use "git add" to track)
havent updated to the latest ratos
with the adaptive mesh
MCU report
Ah, so nothing is actually dirty
You can ignore that
fascinating-indigo•14mo ago
same here, only mcu shows dirty
also attached the moonraker.log but looks near the same to me as already posted. so just a "cosmetic" thingi... 🙂
indeed yes, not sure why the host process was compiled while it was dirty, but it shouldn't matter. As long as its not dirty in the update manager it'll update fine
If the -dirty part is annoying you, go to /configure, click the actions menu in the top right and pick "Flash connected mcu's", that'll recompile and reflash all connected MCU's 🙂
fascinating-indigo•14mo ago
I like it a little bit "dirty"... 😇 thx for your effort!
It reflects the actual state of my printer 🙈
It says the raspberry pi version is dirty, would re-flashing the mcus change anything? I haven't found any issues besides that the prime blob is about 2mm too high and won't stick that way and my mesh is about 0.1mm worse but i think that is the cnc part
Yes it would fix the -dirty on the "Host" mcu. That's about it. It's cosmetic.
Prime being too high and mesh being worse sounds like a mechanical issue. At least i can't reproduce it on any of my printers with different setups. Just ran through testing adaptive mesh changes and it works both with a euclid and a beacon, on minion and v-core. One with 0.08mm mesh (minion), and 0.5mm mesh on the v-core.
Also the only thing the host process is used for is secondary ADXL345's
This i manually moving the nozzle to XYZ 300/0/0
This is the prime blob position with adaptive mesh enabled
Z height of the second picture is 5
What does the console say?
Paste the output, it'll say how much it measured and how much it'll adjust your z offset
Yeah so it's measuring 2mm less next to that prime blob
i will need to check if the klicky even hits the pei in that spot
but it should
If you home G28 Z and do
G1 X265.000 Y20.000 and then do PROBE you should get the same result
Then you can also check if anything is off mechanically at that position
That's the point it is using for the prime blob offset
Looks like you could expand your mesh quite a bit to the right.
Like +35mm
(the probe point is constrained by your defined bed_mesh min/max for safety)the klicky probe doesn't hit the pei. it probes on the aluminium
Ah yeah, that doesn't work 😄
That might be the reason 😂
Hmm.. That also means it adjusts in the wrong direction
Your prime blob should've been lower, not higher
I should probably fix that, and you probably shouldn't update before fixing your bed_mesh minimum 😄
Luckily it adjusted in the wron direction every time.. otherwise my pei would have a dent😅
It would indeed
Wondering if i should build in a threshold. Like throw an error if the offset difference is over 1mm
i think that would be good. 2mm difference shouldnt be possible, even for an abused 500mm RR
Yeah that's what i'm thinking.
from mesh_min 20,20 to 20,30 should be enough, right?
Looks that way yes
this time it hit the PEI but now my z-offset seems to be wrong and i had to hit the emergency stop
made some scratches in the surface
at which point?
looks like my z-offset is overall wrong now. all the lines it tried to print were a lot too low
Is this at zero?
after firmware restart it is, yes. i don't know what it looked like before. i'll quickly do probe_calibrate
Also make sure to do a paper test after G28 by manually babystepping Z to 0.
maybe the probing of the "blob spot" changes the z-value? like homing z on that position. my probe_calibrate result is about 1mm higher than before
No it doesn't. It can't change your config. It only does runtime adjustments.
Did you update yet?
v2.x: v2.0.0-69-ga62032c is the fixed version
That runtime adjustment is subtracted at the end of priming as well, so even if you ran SAVE_CONFIG afterwards, you would only save any runtime gcode offset adjustments you made yourself.
As you can see
RatOS
v2.x: v2.0.0-65-ge10e4e0
Yeah you should update
You're missing all the fixes i made today
didn't know that
updated yesterday
Sorry i should've told you, i'm confusing two threads here. This one was about the -dirty tag on the host mcu, i'm having another discussion about adaptive mesh over here: #Native RatOS Adaptive Bed Mesh hits the bed in prime location
that was my fault, sorry. i came up here with adaptive mesh problems
No worries!
regardless... always update RatOS first correct?