G32 problems, adjusting the wrong way

Haggan90

@dc42 Any clues on what's wrong?

dc42

@haggan90 said in G32 problems, adjusting the wrong way:

@dc42 Any clues on what's wrong?

I'm sorry, I am baffled. Everyone else who reported similar issues had the motors orders not the same in M671 as in M584. In your case, it looks as though the first motor correction didn't happen at all, and the other two motor corrections were double the correct amount.

What happens if you change S3 on your final G30 command in bed.g to S-1 and run G32 several times? That will display the bed probe height errors. Then change it back to S3, run G32 and see what the corrections are, then go back to S-1 to see the new height errors.

Haggan90

@dc42 Ok I just did that, this is the results:
First I did G32 with S-1 4 times.

G32 bed probe heights: 1.849 -1.364 1.682, mean 0.722, deviation from mean 1.477
G32 bed probe heights: 1.748 -1.340 1.683, mean 0.697, deviation from mean 1.441
G32 bed probe heights: 1.760 -1.335 1.593, mean 0.673, deviation from mean 1.422
G32 bed probe heights: 1.729 -1.408 1.605, mean 0.642, deviation from mean 1.451

Then one time with S3
Leadscrew adjustments made: 2.320 2.124 -1.952, points used 3, deviation before 1.581 after 0.000

Then one more time with S-1
G32 bed probe heights: 1.127 -1.914 1.042, mean 0.085, deviation from mean 1.414

Is the probe values in the same order as the probing? The first value is the first probing?

dc42

The height errors are listed in the order of G30 probe points P0 P1 P2.

Try swapping the P2 and P1 parameters on your two G30 lines (you can leave the coordinates alone), so that it stores the points in the order P0 P1 P2. I don't think the order should matter, but people usually probe in the order P0 P1 P2 not P0 P2 P1.

Can you confirm that you are running a recent firmware version?

Haggan90

@dc42 said in G32 problems, adjusting the wrong way:

The height errors are listed in the order of G30 probe points P0 P1 P2.

Try swapping the P2 and P1 parameters on your two G30 lines (you can leave the coordinates alone), so that it stores the points in the order P0 P1 P2. I don't think the order should matter, but people usually probe in the order P0 P1 P2 not P0 P2 P1.

Can you confirm that you are running a recent firmware version?

They were in the order P0, P1, P2.
But I found something that might cause the problem, I've forgot to remove the values for E1(Drive 4) in M92, M566, M203, M201 and M906. Do you think this might be it?

Haggan90

@dc42 I just can't get this to work.. it refuses to calibrate the last stepper in the right way.
It seems like it's working for 2/3 steppers.
This is my last 3 results:

21:11:40G32
Leadscrew adjustments made: 1.081 1.187 -3.137, points used 3, deviation before 1.541 after 0.000
21:07:11G32
Leadscrew adjustments made: 1.447 1.558 -2.405, points used 3, deviation before 1.336 after 0.000
21:06:49G32
Leadscrew adjustments made: 2.048 2.189 -1.888, points used 3, deviation before 1.492 after 0.000

Haggan90

doesn't anyone have any ideas what's wrong here? =/

dc42

Which firmware version are you using? I have 2 reports that this function is broken in the 2.03beta1 release.

Haggan90

@dc42 Yes I'm using the 2.03 Beta, the newest firmware.

Phaedrux

@haggan90 Roll back to 2.02 for now.

Haggan90

@phaedrux I can't, my whole printer is built on the new matrix system

Phaedrux

@haggan90 I think we've come to what they call an impasse.

dc42

Yes, you'll have to wait until I fix it next week in beta 2.

Haggan90

@dc42 ok thank you

ToWi1989

~~I know this is an old topic, but I'm running into exactly the same issue. Did you find a solution to this??~~

My bad, it turns out my coordinates for the leadscrews were way off, I honestly don't even know what I was doing!