G32 not acting as expected

[Deanethiro]

@phaedrux Ok so I changed everything and made the probe points closer to the lead screws and it seems to be doing a better job. I am going to run the tests you suggested and report back with those results.

[dc42]

The order of the probe points in bed.g doesn't matter, except when using bed.g to perform old-style 3, 4 or 5 point bed compensation (which is not the same as bed levelling using independent leadscrews).

The model used by the leadscrew adjustment calculation assumes that the bed is free to tilt about each leadscrew as if it is attached to the leadscrews by gimbals. When using 4 leadscrews, it also assumes that the bed is free to twist. In practice, the bed and leadscrew nuts do not behave exactly like this. Often this means that after applying the corrections, if you probe again you find that smaller corrections in the same direction are still required. If this is the case then you can use the F parameter of the M671 command to deliberately over-correct.

If the corrections needed increase each time instead of decreasing, this usually means that the order of the leadscrews coordinates in the M671 command is not the same as the order of the corresponding motor drivers in M584.

Bed levelling using independent Z motors does not work in firmware 2.03beta1. It does work in 2.02 stable and in 2.03beta2. There are also some older firmware releases in which the calculation for 4 leadscrews was incorrect.

[Deanethiro]

@dc42

Ok good to know, the number has ALWAYS decreased when I did multiple G32 commands. I will give that F parameter a try and see what that does.

I am using firmware 2.02(RTOS) so It sounds like I am safe from math errors?

[dc42]

@deanethiro said in G32 not acting as expected:

I am using firmware 2.02(RTOS) so It sounds like I am safe from math errors?

Yes, the bug in 4-leadscrew levelling was fixed almost a year ago in firmware version 1.20.

[Deanethiro]

@dc42 said in G32 not acting as expected:

Yes, the bug in 4-leadscrew levelling was fixed almost a year ago in firmware version 1.20.

I noticed reading about the M671 command that "For printers that print directly onto a desktop and have levelling feet, this command can be used to define the coordinates of the levelling feet, so that bed probing can be used to calculate and display the adjustments needed to the feet. In this case the displayed corrections must be reversed. For example, "0.2 turn down" means the bed needs to be lowered or the printer raised by 0.2 turn lower at that screw position."

My printer is a Hypercube that has the bed move down in +Z movement do I need to change anything due to that? The height map generated by a g29 seems to be upside down when I tried that so maybe that is the source of my issue?

[dc42]

@deanethiro said in G32 not acting as expected:

@dc42 said in G32 not acting as expected:

Yes, the bug in 4-leadscrew levelling was fixed almost a year ago in firmware version 1.20.

I noticed reading about the M671 command that "For printers that print directly onto a desktop and have levelling feet, this command can be used to define the coordinates of the levelling feet, so that bed probing can be used to calculate and display the adjustments needed to the feet. In this case the displayed corrections must be reversed. For example, "0.2 turn down" means the bed needs to be lowered or the printer raised by 0.2 turn lower at that screw position."

My printer is a Hypercube that has the bed move down in +Z movement do I need to change anything due to that? The height map generated by a g29 seems to be upside down when I tried that so maybe that is the source of my issue?

No, you don't. As I understand it, your issue is that when you run g32 it makes corrections in the correct direction, but it under-corrects. That is very common for the reasons I explained, and is why I added the F parameter.

[Deanethiro]

@dc42

My Main issue is that the G32 seems to level it backwards I guess, the front side of the bed is always too low and the back side of the bed is always too high, it is close enough to print stuff but say when I print a benchy, the skirt on the front is almost not wanting to stick and the skirt towards tho back of the printer is almost transpartent because its being squished so much.

I just tried to use G29 height map and it seems to be doing the same thing. I will draw a diagram to explain what I think it happening

[Deanethiro]

@dc42

Here is what I am talking about

EDIT: forgot to mention on the picture X0 Y0 Z0 is the back left corner but it shows on the back right corner fro the bed mesh

[dc42]

Some observations:

1. You have set up your printer to use a left hand coordinate system. That means you will get mirror image prints. Also the height map displayed by DWC is the mirror image of the actual height map being used. You should change ot to use a right hand coordinate system. If +X is to the right, then +Y must be to the rear and X=0 Y=0 must be at the front left.

2. We can't see the rear left corner of the displayed height map, but if it is as blue as the rear right corner that we can see, then you have either a lot of sag in the Y axis, or a bed that is far from flat.

[Deanethiro]

@dc42 Ok I will change that over to right handed and see if that sorts everything out, the "back corner" on the height map shows it as low but the front in actually low and it sounds like the printer is just confused because of all the screwy coordinates