#X and Y offset but only when leveling
101 messages · Page 1 of 1 (latest)
If I manually tell the printer to move to (0,0) first, then select leveling, it works fine, though if I do so after simply homing it, it does not
And where does the printer think 0,0 is
Front left
It knows it and I can tell it to move there
But it does not start its levelling from there unless you move it first.
And I would assume the command is supposed to tell it to 0,0 first automatically
Though I am new to this
potentially sounds like you have got some sizes mixed up in your configuration.
two requests:
can you post a short video of you just homing X/Y
can you upload a klippy log file
additionally- when the toolhead is in this position, which X Y numbers show in mainsail
The position it started is 175,175
and at the end?
350.01,350.00
I haven’t checked if it messes with prints yet, as I am just going through the startup tests
Other than the above, it passed the rest of its tests (other than the probe accuracy having a high sd) and the only other issue is that the motors seem a bit loud when idling
so i've been through your config.
everything relating to AB/XY configuration looks correct
QGL config looks good
G32 macro is as expected
Print start macro will need some work but that can be sorted later
No odd uses of absolute vs relative positioning
No actual errors in the log which is odd- i might expect some thing like "endstop triggered before retract" or things like that
as much as i hate making people make their printers grind away, can you:
-
screenshot the control you are using to trigger the issue
-
take a short video of the issue happening
I’m getting the feeling I should keep replacement belts just in case lol
it shouldn't come to that but never a bad thing to have in stock
I stopped it a bit early, but I think you get the gist
Not sure what’s with the noise at the start either
thats a motor skipping. the whole thing is quite odd, i'm going to see if there are more brains around
this whole time you've been using klipperscreen to control homing and QGL attempts?
Both that and the interface over wifi (same result)
and it's never done a successful QGL (i saw some bed mesh attempts in the log)
QGL?
quad gantry level.
It has, if I move to 0,0 first
oh yes. duh.
Proof
ok. lets hold on to see if any of the other helping team have some ideas as i'm a bit stumped
if it wasn't using physical endstops, I would blame sensorless setup, but that's not the case... hmm
If it helps, it is a minor running gag in my friend group that I run into weird bugs a lot more often than normal.
At least I get a lot of practice troubleshooting I guess
i had this patch when i was in the army...
That is amazing
All I got was my usual username lol
(From the bugs, not the army)
I’ll test the extruder and printing now
If that works I can at least use the printer and make the other parts I need for it
that was definitely a fresh klippy log, yeah? not made any secret config changes since then?
from the future!
It wasnt the first but the (1) means I didnt mix them up
I am australian
its 1:19 now
one idea has just come up- in your [printer] section can you drop the max_accel from 10000 to 3000 and see where that gets us
exactly the same behaviour? you've updated and restarted klipper?
Ok, I have fixed it
It was not the software at all
And if I was one of the people in the threads I usually look at when troubleshooting I would leave it at that lol
The belt near the left idler had managed to slide up its gear and run inside the channel of the extrusion a bit
My guess is that moving the gantry forward forced it into an almost normal position
So from 0,0 it worked
But when starting from the middle it would seize
I’m not exactly sure why that problem resulted in that way, but I shoved one of the black thingies that came with the kit into the channel
So the belt can’t slip in there
you will certainly need to check your pulley heights and belt tension
The right side is perfectly fine, just the left, I only noticed cause there were little particles of ground belt around the z0 exit
I loosened the tension a little in that idler as well
it could be worth just checking some photos of your belt paths all the way round
Thanks though, eliminating the software side was helpful, as I assumed I messed that up
front idlers?
which pully let the belt slip? did you get a pic of that?
This one
hmm
Though the slip was only visible from the side in the crack between the extrusions
The gap in question ^
i wouldn't expect a front idler to cause this sort of chaos unless it was binding, or the belt was walking severely off the pulley and jamming the travel.
and if the belt is walking that much then something is likely out of alignment with that front idler
can you expand on/demonstrate this at all?
#1521154403065925834 message I know it's probably a trick of the photo angle, but does this look wonky a bit?
This thing
I also used one to cover the light bar cables running down one extrusion
have you gone through belt tensioning at all?
I did tension them a bit
i feel now would be a good time to check them- https://docs.vorondesign.com/tuning/secondary_printer_tuning.html#belt-tension
I did see this, but hadn’t gotten to that step yet
ahh. bad tension could definitely cause the issue you saw... run through that and let us know how it goes
I will… tomorrow
certainly no rush 😉
Still figuring out the tuning, but in my opposite of an expert opinion, they may have been a bit tight
Just a wee bit
I also managed to misroute the back left z belt at the bottom
I’m not sure how I even managed that
Probably by working on it at 4 am a few nights ago
🙂 never work on your printer tired. recipe for disaster