G32 problems, adjusting the wrong way

dc42

Check that you have specified the leadscrew XY coordinates in M671 in the same order as you specified the corresponding Z motor driver numbers in M584.

Haggan90

@dc42 Yes they should be correct.

Haggan90

@dc42 I've tripple checked both the config.g and bed.g now and I can't find anything wrong.
It seems like all the steppers are calibrating the same amount, so the bed just get's worse for every G32..

dc42

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

@dc42 I've tripple checked both the config.g and bed.g now and I can't find anything wrong.
It seems like all the steppers are calibrating the same amount, so the bed just get's worse for every G32..

Those are exactly the symptoms of having the M671 coordinates not listed in the same order as the Z drivers in M584.

Haggan90

@dc42 I think so to, but somehow I can't get it to work.
Ok so here's my config.g again:

; Drives						
M584 X0 U6 Y1 Z2:4:5 E3				; set 3 Z drivers and add one U driver
M569 P0 S1                                      ; Drive 0 goes forwards
M569 P1 S0                                      ; Drive 1 goes backwards
M569 P2 S0                                      ; Drive 2 goes backwards
M569 P3 S1                                      ; Drive 3 goes forwards
M569 P4 S0                                      ; Drive 4 goes backwards
M569 P5 S0                                      ; Drive 5 goes backwards
M569 P6 S1                                      ; Drive 6 goes forwards

M669 K0 Y1:1:0:-1				; set Y to react with X and U

; Defining X and Y coordinates of the leadscrews
M671 X580:580:-80 Y0:490:200 S5 		; leadscrews at front right, rear right and middle left

And here's how all is connected:
Imgur

aidar

I dont know if it matters, but your probe point numbers are not in "logical" order, you have P0, P2, P1 for some reason.

dc42

The order of the probe points in bed.g doesn't matter. What does matter is:

The bed moves the right way. Users with beds that move in the Z direction sometimes get this wrong; on these printers, +Z moves the bed down.
The order of coordinates in M572 matches the order of the Z drivers in M584. According to your config.g, driver 2 (Z motor output) drives the leadscrew at X=580 Y=0, driver 4 (E1 output) drives the leadscrew at X=580 Y=490, and driver 5 (E2 motor output on the DueX) drives the leadscrew at X=-80 Y=200. Is that correct?

Haggan90

@dc42 Yes that is correct, and the bed moves in +Z when it goes down.

dc42

Can you see all 3 leadscrews moving when it makes the correction? It may help to reduce the Z movement speed in M203 to make it easier to watch them.

Is 750mm/min Z speed (in your M203 command) achievable on your printer?

Haggan90

@dc42 Yes, all 3 are moving when it makes the correction, but I'm not sure if they are movin the exact same distance.
You can clearly see that the left one, the one who is alone, should adjust in -Z (move bed up) but instead it's adjusting in +Z (moves bed down).

750mm/min should be possible. I had it set to 500mm/min at first but then my BlTouch were hitting the bed after probing (the bed was to slow to move down from the probe after probing).

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.