Gantry Slams into Front Belt Tensioners
I have everything working so well and I've tried every type of calibration I can find but nothing I do prevents the gantry from slamming into the front belt tensioners when it does the nozzle wipe. Here is what the console shows: RatOS: Auto calibration nozzle wipe with probe result 0.002165627786482105...
Solution:Jump to solution
```properties
[stepper_x]
position_min: 0
position_max: 400
position_endstop: 0...
61 Replies
Probably want to drop your printer.cfg and/or Ratos.cfg files here
yup rule #2 from https://discord.com/channels/582187371529764864/1233461645167169576
The # makes those settings apply to the previous section, which is
[stepper_x].
Looks like this is just the usual bad position_min/max/endstop calibration. Do it again, and make sure 0,0 as in the front left corner of the bed.
You also want to move those to after the existing settings or they'll just be overwritten.
For some reason you broke up the user overrides header and added you modifications before the header explanation. You should add your stuff to the very end of that section. Even better, just modify the limits that are already there, they're printed to the file exactly so that you can modify them directly.It even says so in the file:
Custom shit goes here
Modify your positions here
Thank you for your feedback. I originally modified the positions exactly where you recommended, where the calibration settings already were. It didn’t fix anything so in reading the rules of where modifications must go, I moved them to the overrides section. Are you telling me that all the hidden code in things like prime blob and nozzle wipe are not going to ignore xy mins, maxs and offsets set in this section.
Are you telling me that all the hidden code in things like prime blob and nozzle wipe are not going to ignore xy mins, maxs and offsets set in this section.Yes. What comes last is what klipper regards as the truth. That's how overrides work. Your current [stepper_x] section doesn't do anything You can see it in your klippy.log, klipper prints the final merged configuration there.
I spent a couple of hours calibrating everything. Nothing changed. But I trust you know a whole lot more than I do so I’ll try again.
Nothing changed.Then you didn't put it here: https://discord.com/channels/582187371529764864/1263533124957114420/1263629059313762375 Or you didn't save and restart. Before you continue, are you absolutely sure your toolhead is moving correctly?
I only posted my last printer.cfg and RatOS.cfg, not the 15 iterations I tried before.
I was explaining the only way a change to what i'm pointing to in the image wouldn't work.
There's another way, you could've copied any of those stepper sections and pasted them after the ones already in printer.cfg by mistake and not noticed.
But that's about it.
That's provided you're not trying to calibrate a printer with incorrect kinematics (as in, you didn't do sanity checks for toolhead movement).
I understand the sequencing now. My tool head prints great. I just don’t know how much longer the printed parts can withstand the collisions.
I'm not talking about how it prints. I'm talking about how it moves when you use the buttons via mainsail.
if down moves it forward and right moves it to the right, you're good to calibrate
Clean your printer.cfg from your overrides and stick to the sections that were already there.
It moves perfectly. I got it exactly where I wanted it to avoid collisions, both x and y. I ran Get_Position to ascertain where I wanted 0,0 to be. Entered the new coordinates in stepper x and stepper y. Saved config. But I must have done something wrong.
Yeah that's not how you calibrate position min/max/endstop
Especially since it looks like you're using a V-Core 3 which homes at Y max
That means if position_endstop: 400 makes the toolhead slam into the frame at 0,0, you need a smaller position_endstop and position_max.
390 would move 0,0 10mm towards the back of the printer.
Makes sense?
Alternatively you can physically move the endstop
I’ll bet 90% of users didn’t know this. I tried every way to research this and finally found a guide devoted to Creality of all things.
It's math and geometry
I majored in math in college. It’s a lot more than math.
You have a rectangle defined by position_min and position_max on x and y. The origin is defined by your endstops. So if you tell the software that your endstop is at 400, then logically that makes the software think that 0,0 is 400mm away from that endstop. You say that makes it slam into the front. It's all simple math from here.
The endstop is your boundary. that defines the location of your rectangle in physical space.
You make it sound so simple. And I think I’ll actually be able to get it right. You should copy and paste this into your docs folder in RatOS. I spent a lot of time reading every doc. Didn’t help.
I think an animation is the only way to make it click, it should be instantly obvious when you see it.
Does this help?
Not only does it help, I planned to set endstop, and max at 350 just to test it.
We need someone to draw a ton of these, like a "printer software 101" series.
BTW, I just counted 29 printer.cfgs since I started trying to solve this.
oof
I was about to chime in when i saw you posted that voron guide
But for some reason i thought "i guess that's good enough".
I'm assuming the "homing at Y-Max" part is probably the cause of the confusion
Vorons home at 0,0
Absolutely
I know where the physical endstop is. I just didn’t tie physical to min.
But when you look at the text, it’s rather obvious, isn’t it.
I think there's just too much bad info out there
Causes more confusion and overthinking than anything else
there's a lot of "what" and not much about "how" or "why"
And most of it is wrong 😂
Especially on reddit. Don't go to reddit for 3d printing advice.
My problem is that I love to tinker. Some just love to print. I’ve probably got $1,000 in upgrades, improvements, etc. Most just ruin good printing.
Of course, y max, endstop 350 crashed because z tilt goes to 370. More hidden code 😉
It's prolly a little aggressive to go 350 anyway, but yeah the z_tilt points are defined per size (you can see the specific size include in RatOS.cfg if you want to see this "hidden" configuration), if you radically modify the size parameters you need to fix what's defined in there too.
I think you should physically adjust your endstop though.
Also, you don't need to do a full print to test this
Just home and go
G0 X0 Y0I’m crashing on every print attempt. All out of range errors. I did physically move the endstop.
If you moved the endstop backwards, you should be fine with the default 400
if not, there's something mechanically wrong
It’s just not that easy. I move it back and the beacon tries to scan beyond the bed. I change the y position min and I get out of range error. There must be a very fine line where it will work.
Is G0, X0, Y0 on the command line? That returns an out of range error.
no commas
I didnt use commas.
0,0 shouldn't be out of range. Something is misconfigured still :/
And, with all the fixes, my gantry still slams into the front.
stepper_y has a position_min of
4?I thought that might help.
I measured. I have 430mm from endstop to front. Set at 390 and gantry still slams.
The position_min of
4 is what is causing the out-of-range error when you try G0 X0 Y0Is the command Go X0 Y0
no
So, G0 X0 Y0 hits the front. And ideas?
It’s just not that easy. I move it back and the beacon tries to scan beyond the bed.This is a separate issue. Beacon is not default V-Core 3 hardware, so you need to adjust the z_tilt points and bed_mesh min/max to accomodate it. it does not. Yes, you're having mechanical problems. Please post a picture of your printer, as seen from above. There must be mods preventing you from utilizing the full physical dimensions of your printer. I think at this point it's probably easiest if i just provide you the answer. But i'm gonna need to see what i'm dealing with to do that.
It does print a perfect first layer😜
Ah yes, you've added tensioners that block the movement of your X gantry
i don't think thats a 400? Maybe it is. I have a 300 and just my eye was looking at the printhead vs the plate. I easily could be wrong
You effectively cut off around 50mm of print space.
I'm pretty sure it's a 400, at least this is what my 400 looks like 😄
Alrighty then. So we're gonna have to limit max y and modify z_tilt and bed mesh
Gimme a sec
The nozzle is right over the corner. So maybe 10mm. But I can accept a smaller print bed to end the collisions. That’s what I thought endstop, min, max does?
Solution
Put that at the end of your printer.cfg (before the klipper managed section that looks like a giant comment block)
Updated: Removed the z_positions from [z_tilt] as you don't need those (those define the pivot points and don't change from the default).
It does, you just didn't limit it enough, and when you went overboard (350) you didn't fix all the other limits that rely on the physical dimensions.
Update: added position_min as i saw you still had bad values for those in printer.cfg.
Do I delete those same lines above or will Klipper only read the last?
IT reads all of it, but the latter values override the former
Sections are merged chronologically
(this is explained in the RatOS docs)
Includes & Overrides | RatOS
RatOS uses a modular configuration that heavily takes advantage of the config file include and merge logic in Klipper. For this reason, the order of includes and overrides are very important, do not change the order of the configuration unless you know what you're doing.
Ie, you don't need to delete them, but you can if that makes it easier for you to reason about.
gotta go
It works perfectly. 😜