quad gantry leveling problems

[still gust]

I have a formbot 2.4 pro kit, every time I try to quad gantry level, the z2 and z3 motors move up and throw the gantry further out of alignment. I know I have my motors wired right as in the documentation and I am pretty sure I have the config file set up right. What do I need to do?

[mortal vale]

switch z2 and z3 with z0 and z1 drivers and see if anything changes

[summer depot]

Work through this page and make sure everything is working properly. https://docs.vorondesign.com/build/startup/

[still gust]

reversing the z0,z1 drivers with z2,z3 the problem switches to the other side

[mortal vale]

so you my friend have bad drivers

replace them and you should be good

[still gust]

That sucks,

[mortal vale]

not really... cheap fix

better then meesing around with it for days lol

[still gust]

Alright, I will grab a set when I get paid next

[mortal vale]

dont mess with it till you change them. you can split your motor mounts or worst

the buzz motor thing does not do a good job at showing a driver issue

[still gust]

Thanks, I thought I was going crazy

[summer depot]

I'm assuming that since you are doing QGL, your motors move in the right direction during homing X, Y, and Z. If your Z homing is successful, then all your Z motors are moving in the right direction. Can you confirm this?

[fading tiger]

Hi @still gust i had something like that on my first go too. i had to add/remove the ! on the "dir_pin" in my printer.fcg
on the two drives that move the wrong way, Try adding or removing the ! on them.
You might already know this, but just in case 🙂
The ! defines inversion of the setting. so adding one, or removing one will invert your motor direction.

I also have a formbot kit, so i'm pretty sure its the same thing, as the wires are probably wired the same way.

[still gust]

That is correct

If I removed the ! Then it wouldn't home right

[shut lake]

Your arrow is pointing to the enable_pin. Don't think you want to flip that...

[fading tiger]

hah, yes that is true, and you are very correct.

it was supposed to point to the dir_pin.

sorry for any confusion it may have caused

[shut lake]

When I built my Formbot kit I had to reverse direction on Z steppers. Rushed through the config edits and accidentally reversed the enables. That was another 15 minutes of aggravation to realize.

[fading tiger]

i should probably not go trough these posts at 4 in the morning >.<

[fading tiger]

i did the exact same thing with my formbot kit , haha

[still gust]

I suppose I can plug the printer back in and test that

[still gust]

I tested flipping the dir pin on z3, all it did was make the printer unable to home. the z3 would go up when homing instead of down like the others

good thing I ordered the replacement ones. however, I have to wait a couple weeks for the part to ship from china

[pine sable]

Talk us through what happens when you qgl

What order does the printer visit the corners?

Also i would almost guarantee you don't have a driver issue

The sort of thing you describe is almost always config

[still gust]

I tried reversing the dir pin on z3 and it wouldn't home anymore. It went up when the other corners when down. I couldn't do qgl because I couldn't home

I don't want to break my printed parts

[pine sable]

So flip that pin back, that advice was obviously wrong

And then once you can home again, do a pass of qgl, and describe exactly which order it visits the corners

[still gust]

I will do so when I get homs

Home

[still gust]

It visits z0, z3, z2, z1 in that order

[pine sable]

So I'm trying to avoid making any assumptions here, so could you restate that in terms of "front left", "back right" , etc

But at first glance, that doesn't sound right. So we're probably actually talking about incorrect configuration on the x/y movement axes, and qgl is just where you're noticing the resulting side effects

[still gust]

Facing the printer it goes front left, front right, back right, back left

[pine sable]

Ya...so that's not right.

Should be front left, back left

So let's have a look at your homing

When you do g28 x, what happens?

[still gust]

It goes to the right side of the printer

[pine sable]

okay, and when it gets there, does it think its at x0, or at x(max) ?

[still gust]

X max

[pine sable]

Alright. And y?

(Same two questions)

[still gust]

Goes to the back of the printer at y max

[pine sable]

Okay, so those sound correct

May I see your [quad_gantry_level] config block?

[still gust]

I have the safe z home set to 175,175

[pine sable]

That actually doesn't matter much for this

[pine sable]

That looks right...

I must be missing something

Can you shoot video of a g28, followed by a QUAD_GANTRY_LEVEL ?

(Stopping the qgl before anything gets too weird )

[still gust]

https://mega.nz/file/aCIHgZBY#61p1WIL8kyDDXgDlx1_GmKTiMXAo7k8Az0J8niGdxyk

I couldn't upload to discord, don't have nitro

[pine sable]

We have enough sponsors on this discord you don't actually need nitro...I think even with max nitro, it caps you at 100meg though

But that's all good. Mega works too

So the first thing I notice, is that when homing, it moves to the back first, then the right

Which strongly suggests that when you do g28 x it actually goes to the back, not the right.

Can you confirm that?

[still gust]

Yes

That is what happens

[pine sable]

Well then

This whole problem is very simple

A quick at the movement chart

From the startup guide.

Identifies that when x max is the back, and y max is the right, we need to invert stepper a

[still gust]

I will reverse the configuration then

[pine sable]

No. Stop

[still gust]

Ok

[pine sable]

What *exactly * do you mean by "reverse the configuration"

[still gust]

I mean swap x with y

[pine sable]

Why the heck would you do that?

We've identified that one particular motor is running backwards

The solution is to reconfigure the dir pin on that single motor

[still gust]

Ok, I spoke wrong

[pine sable]

Not to start swapping entire units

Motor "a" is [stepper_y]

So all you need to do is invert (add/remove a !) its dir_pin

Now, this raises a possible secondary issue though

Are you using regular endstops? Or sensorless homing?

[still gust]

Regular endstops

Except for z, that is on the proble

Probe

[pine sable]

So from the fact that it was homing successfully, odds are you have the x and y endstops swapped

But test that please, don't just take my word

The X endstop is the one on the side of the pod

And y is the one on the back

Please use query_endstops and trigger them manually with your finger to confirm whether they're patched correctly, or swapped

[still gust]

They are reversed

Should have triggered x but triggered y instead

[pine sable]

THAT you probably should solve with a connector swap

[still gust]

Ok

That solved that part

[pine sable]

Now try qgl again

[still gust]

I did and it worked

Now I feel dumb

[pine sable]

Don't feel too bad. Getting tangled up in the bizarre movement systems of corexy ....you're far from the first, and you won't be the last.

[still gust]

True, at least I didn't give up

[pine sable]

Core xy is weird at the best of times, and the misleading way klipper labels the motors makes it even worse

[mortal vale]

now im confused... i asked the op to swap around z stepper drivers (i had a very similar issue). he said that the problem followed the stepper drivers. how can this be the case if the problem was in the config?

[pine sable]

I don't know for sure, I suspect there was miscommunication about what that swap actually involves. I suspect motors got swapped, instead of actual drivers

[mortal vale]

i c... i thought i was being clear

[still gust]

let me try to clarify, I fixed the problem by reversing the x and y endstops on the octopus board then inverting a motor dir pin

when I swapped the z drives it made the problem move from 1 side to the other so I thought my stepper drivers were bad

what I did was move the wires, I thought that is what you meant