"Must home Axis first" When trying to home after fresh 2.0.2 Install
Just updated to a fresh install of 2.0.2, made all the updates and did not have any errors in Mainsail anymore.
I verified all end stops work and axis move correctly with "SET_CENTER_KINEMATIC_POSITION", the BL-Touch failed homing (my fault: triggered at a different height by me) and I tried rehoming all axis. But whenever I try to rehome all Axis I get the error "Must home axis first: 0.000 0.000 15.000 [0.000]". Happens also after a restart.
I also added my old printer.cfg which I migrated some settings from.
EDIT: When I send a "SET_CENTER_KINEMATIC_POSITION" command first, the homing works afterwards until I disable all motors or restart.
58 Replies
I also tried inserting this from my old printer.cfg but no luck
Safe Z Home (Physical endstops only)
[safe_z_home]
home_xy_position: 150,150 # 300mm printer
#home_xy_position: 200,200 # 400mm printer
#home_xy_position: 250,250 # 500mm printer
So you get "must home axis" when you press Home after a fresh restart?
You should have gone with 2.1...
let me check the files
can´t see anything that can mess homing sequence...
do you mind giving a try at 2.1? 2.x is not in development anymore.
Use the current printer.cfg to correct motor directions and you can also save some of the overrides (like skew correction) if you only did RatOS flashing and the machine has nothing different.
That was my initial thought but didn't want to reflash again as soon as the full release is out.
I will try 2.1 on sunday and mark this as solved if it works.
I need to rerun the skew correction since I upgraded to the 3.1 movement system (bed arms are still 3.0, they will be swapped next week). But everything worked after the mechanical upgrade, I just needed to upgrade to 2.0.2 because upgrading to the latest 1.x version bricked klipperscreen for me.
It was just strange to me since it didn't let me home because it was not homed... thats odd
Same problem here after the last Klipper update (running RatOs 2.0)
maybe a bug?
I’m not sure. There were not many bug changes on 2.0 since 2.1 is on the making…
i think is related to klipper only
and last commits
Commits on Jan 21, 2025
force_move: Use strings for axes to clear in clear_homing_state()
toolhead: Pass set_position() homing_axes parameter as a string
stepper_enable: Directly call clear_homing_state() on motor off event
but i m not sure, could you please check?
Also this one maybe
force_move: Implement CLEAR for SET_KINEMATIC_POSITION (#6262)
@miklschmidt if you have a minute, please…
thank you
I did nothing… just asking for God to help 🤪
maybe it is a rare error but can help people that found it
i temporary fixed with set kinematic position command and then the printer can home like before
I am glad to not be the only one.
So far I couldn't manage to get 2.1 to run. Something with the Network configuration seems to be my problem, it crashed my whole network after wifi setup (but still managed to update, don't ask my why) and now it tells me the updated ratos package is invalid and can't get the update from git anymore "repository not initialized" IIRC. Etherenet didn't work at all. Didn't get an IP from the DHCP (not listed in the Router) same cable and connection like with 2.0 (where it worked)
I will now try to reflash again and try my luck with Ethernet.
Ssh to the raspberry and send
ratos doctor
Ok this does not work for me... 2.1 is a mess somehow. First time I wasn't able to connect via ethernet, it just didnt get an IP somehow (no restrictions on the router or anything). Wifi worked and but after a restart everything went south. Reflashed 2.1 and got Ethernet working + did initial setup and updates. Let it sit for a few days because I didn't have time and now I am again back to not getting a IP Adress via ethernet.
I’m sorry but so many people using it without issues shows the mess is not RatOS 2.1 😉
Can you share ratos-debug.zip? Please
you might be right.... that comment clearly got written in the "heat of the moment" sorry
it seems that SOMEHOW, since upgrading to 2.1 the printer sometimes does not want to play ball with my switch
but there clearly are some problems... when starting the printer it takes many retrys to connect to klipper, I always have to wait for some time and then just manually retry and it works .... why? no clue. Also the network option in klipperscreen doesn't work (which might be a hint why it does produce network problems?)
and without wanting to be disrespectful about the huge work done on ratos... its in a "beta" state for months now, so there has to be a cause why its not out of the RC2 state
It is RC3 for some time now…
And the only reason why it is not full release by now is documentation, exclusively!
Btw: network manager in klipperscreen is a mess and nothing to do with RatOs. And probably this is also messing your connection.
The correct way to connect to wifi is connecting ti the rpi hotspot and doing it in the configurator.
Either klipperscreen and wpa_supplicant files are adviseable against
Updated klipper but the error still remain
after the use of SET_KINEMATIC_POSITION you are supposed to turn motors off
RatOS even warns you in the console about that
You are right, but there is just the RC2 to download from github or am I doing something wrong? I got the RC3 via the update on the printer itsself.
One thing I would like to add just to be clear: ratrig does an amazing job developing their systems (software and hardware) and its the most accessible "diy" printer there is in my opinion. So even with those hickups, awesome support and good work!
its in a "beta" state for months nowits not, Beta and RC are two different things
I restarted the printer multiple times in between, problem still remained
ok, but the printer doesnt make the Home from the beginning
thats why "beta" was in quotes, I am not a software developer. I know that RC means "its damn close to release" but it how can I know why it isnt released ...
if i restart the printer, switching Off and turning ON, the error remains
same for me, I followed the procedure in the doc
before this update the printer worked fine
now i cant homing before pressing SET KINEMATC POSITION
Something broke the HOME
after the command SET KINEMATC POSITION i can launch a print and works fine
but after the END Print i cannot make HOME, because again i got the same error
i highly suggest to use V2.1
i tried, but without success
it's not a big problem for me press SET KINEMATC POSITION before Homing
i prefer to stay with RatOS 2.0 cause is "stable"
i can buy another SD and try a fresh installation of RatOS 2.1
what printer is this?
Vcore 3 .1 400
i assume the bltouch is messing arround with it somehow
maybe they updated the klipper plugin
its a very untypical error
i'm using another probe, BDSensor
Maybe i can add the SET KINEMATC POSITION command into HOMING and START PRINT
i think is not dangerous, or i m wrong?
this error basically means that the X or Y has not been homed before you want to Home Z
this error is only located n the klipper check endstop functins
so something is messed up and as said its not a typical error with ratos
yeah i know, it's klipper issue
nothing to do with ratOS
BDsensor?
yes, it's like Eddy Probe
or Beacon
well, this is actually not supproted in ratos
but it's not an error with this sensor
because before the klipper update is worked fine
however, i can help you if you use V2.1
ok, i can give a chance to 2.1
you could also rollback to an older klipper version
uh, is it easy to do?
i can try to see if the rollback fix this little issue
If you don't experience network problems like I did, the 2.1 setup is quite straight forward tbh.
Ok I totally jinxed it..... the bltouch somehow wont deploy on 2.1 "command unknown"
again and again I have to remind myself about "never change a running system".... why, why was I so stupid
ok own stupid mistake, nvm
wow I give you that.... the configurator is awesome!
also for changing stuff you apperantly forgot to set
Any bed sensor that is not supported in RatOS messes all the homing routines. Micro probe, btt eddy, bd sensor, whatever.
You will need to re-write the homing macros.
but before the last klipper update it worked
with the standard Homing macros
and in the case of DBWL he use BL touch
so i think is not the Probe problem
Probably something changed in the scripts.
yeah
in the last commits
From klipper 😉
yes i think so
not RatOS issue i know
only Klipper in this case
Solution
Can report, its alive and working, now to the fun part.... tuning
I am having an issue with homing on a v-chonk, RatOS V2.1 RC3. When homing z the tool head stays at
location 0,0, which puts the superpinda sensor off the bed. Since the sensor can't trigger, the bed crashes into the hotend. I would have thought all axes would return to safe_home_z postion after homing.
Please open your own thread with your own things you've tried and config files. Thanks!
did you ever solve it? This thread is marked as solve after OP reinstalled the newer version... but I super curious... I had chat gpt search both the ratOS and klipper githubs looking for any mentiion of "MUST HOME AXIS FIRST" and it found nothing. It happened to me (i think) after uncommenting [bltouch} but i have been as far down that rabbit hole as I can see (not far) and found nothing
It would be in klipper source code not Rat-OS
That's not helpful.
Open your own thread if you are looking for help please.
oh I put it after the base setup section which imports the include file. [include RatOS/homing.cfg]