G32 not acting as expected

Deanethiro

@Phaedrux Yes it does that, is that not okay? I read this and it did not imply that I needed to do it in any sort or order besides the order that the motors were defined. So how should I change this to make it better?

Phaedrux

I think it just needs to be in the same order the lead screws are defined. I would think that would usually be in a circular clockwise pattern, but I suppose it need not be? Not sure.

Using 4 lead screws isn't recommended due to the added potential for binding, which seems possible in this case. What happens if you even them up manually and then run G32? Does it stay level or get worse? What happens if you run G32 a few times in a row, does it improve?

Deanethiro

@phaedrux said in G32 not acting as expected:

Using 4 lead screws isn't recommended due to the added potential for binding, which seems possible in this case. What happens if you even them up manually and then run G32? Does it stay level or get worse? What happens if you run G32 a few times in a row, does it improve?

If I run it a few times in a row the deviation number gets lower and lower but it still looks uneven , when I print the side that looks like it is sticking up slightly has a more crushed layer line. I have not tried manually fixing it and running it again but I will try that once this print finishes and report back. If I have to go to three I will but I really liked the idea of 4 points of control

Phaedrux

4 points is possible but there needs to be enough flex in the bed frame to allow for it to go out of true during leveling without causing binding.

I assume you're using a BLtouch as your probe. How consistent are the probe results? If the probe isn't consistent that could explain poor leveling results. I notice you're using the older P5 probe type. Consider switching to the dedicated BLTouch probe type P9. You can then also reduce the trigger threshold value in G31 P500 to G31 P25, both of which may help make the BLTouch trigger more responsive.

Also, what firmware version are you running? Upgrade to 2.02 if you aren't already running it.

Deanethiro

@phaedrux said in G32 not acting as expected:

I assume you're using a BLtouch as your probe. How consistent are the probe results? If the probe isn't consistent that could explain poor leveling results. I notice you're using the older P5 probe type. Consider switching to the dedicated BLTouch probe type P9. You can then also reduce the trigger threshold value in G31 P500 to G31 P25, both of which may help make the BLTouch trigger more responsive.

Great tips I will try all that and report back!

Phaedrux

@deanethiro I forgot to mention also that your probe speed is rather high for the BLTouch. Try M558 F120 instead.

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 alt text

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:

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.
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