Mesh Confusion

Phaedrux

Order dependence
M584 must come earlier in config.g than any M350 and M906 commands. If it creates new axes, it must also be earlier than any M92, M201, M203, M208, M350, M566, M574, M667 and M669 commands.

https://duet3d.dozuki.com/Wiki/M584

M584 X0.0 Y0.1 Z0.2 E1.1                     ; set drive mapping
M350 X16 Y16 Z16 E16 I1                      ; configure microstepping with interpolation
M92 X80.00 Y80.00 Z400.00 E727.00            ; set steps per mm
M566 X2000 Y2000 Z602.65 E250                ; set maximum instantaneous speed changes (mm/min)
M203 X20000 Y20000 Z1500 E3200               ; set maximum speeds (mm/min)
M201 X1500 Y1500 Z500 E3200                  ; set accelerations (mm/s^2)
M906 X1200 Y1200 Z1200 E420 I60              ; set motor currents (mA) and motor idle factor in per cent
M84 S60                                      ; Set idle timeout

; Multiple Z motors
M584 Z0.2:0.3:0.4:0.5                        ; assigning all the Z drives

Mapping the Z motors after the axis settings have been applied might be a problem, but not sure that's a smoking gun.

Do the order of your points in M671 match the order of the drives in M584?

If you send M98 P"config.g" do you get any errors?

kcress

@phaedrux Hi.
I corrected the M584 - M669 precedence issue : No obvious change.

I also put the mapping of the 4 Z motors into the same M584 statement to bury any smoking gun.

M584 X0.0 Y0.1 Z0.2:0.3:0.4:0.5 E1.1         ; set drive mapping (combining all assignments in one line)

Also no change.

I had the entire heavy printer propped up at an angle and thought maybe that was causing some frame torque issue. I dropped it down level and closed up everything.

No change.

I then ran G32 which runs in turn runs bed.g which looks like this:

M561                         ; clears any bed transform

G30 P0 X20 Y20 Z-99999       ; probe (-99999) near a leadscrew X0,Y0
G30 P1 X20 Y380 Z-99999      ; probe near a leadscrew X0,Y400
G30 P2 X380 Y380 Z-99999     ; probe near a leadscrew X400,Y400
G30 P3 X380 Y20 Z-99999 S4   ; probe near a leadscrew X400,Y0 and calibrate 4 Z axis motors (Tram them)

Pretty sure the drives are in the same order of points used in M671.

I've then run G32 multiple times right after each other.

Recall my 4 Z motors are ordered this way:

; --- drive map ---
;    _______
;   | 3 | 4 |
;   | ----- |
;   | 2 | 5 |
;    -------
;     front

Here's what three tests in a row look like!
The third faulted refusing to do a tram calculation because the error exceeded my 5mm limit. (Whole sequence has been repeated several times with a fault eventually after 3 or 4 trammings.)

;          --- drive map ---
                  BACK
;          -----------------
; pass 1  | -2.429 | -0.012 |
; pass 2  | -4.943 |  0.010 |
; pass 3  | -7.348 |  0.019 |
;         | ------ | ------ |
; pass 1  |  0.038 |  2.486 |
; pass 2  |  0.531 |  2.427 |
; pass 3  |  0.387 |  0.268 |
;          -----------------
;                FRONT

I'm going crazy here after days of these results.

Any Ideas?

rjenkinsgb

Try changing the probe point order?

Looking a the the examples for bed levelling, the three motor one does not use the same probe order as motor / screw order??
https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors

It may be using left-right and back-front order, though its difficult to be sure with only three points.

eg. possibly

G30 P0 X20 Y380 Z-99999      ; probe X0,Y400 - Left Back
G30 P1 X380 Y380 Z-99999     ; probe X400,Y400 - Right Back
G30 P2 X20 Y20 Z-99999       ; probe X0,Y0 - Left Front
G30 P3 X380 Y20 Z-99999 S4   ; probe X400,Y0 - Right Front & cal.

kcress

@rjenkinsgb Robert!! You're correct. That example is crazy. Using LR then RR the Fcenter while having defined them in LR/FC/RR order.

I agree it seems like there is a mismatch on my machine as each time the correction gets worse with the LR tower. Unhelpfully not much guidance anywhere on how to figure out which two are backwards.

Clearly my LR is goes haywire fast. The next worst I guess is my FR. But what does this mean? That the LR and FR are backwards or the LF and RR? Ugh.

I swapped 3 and 5 (LR and RF). The error between subsequent passes grew on the the LR and RF values.
LR pass 1 1.023
LR pass 2 2.233

RF pass 1 -1.214
RF pass 2 -2.210

Instead swapped LF with RR.
Very bad.

Then instead swapped LR with LF....
The LR stepper started doing something odd. Either losing steps or adding steps. It aborted with a "too large error", (more than 5mm).

rjenkinsgb

@kcress
Have you tried the exact sequence I suggested? I'm not sure from the various swaps you mention..

engikeneer

@rjenkinsgb the probe point order is irrelevant. The method simply stores all the points and puts a plane through them to work out the offsets.
You can have more probe points than you have motors too (I probe 6 points for my 3 z motors), and it will do a least squares fit for the plane.

@kcress have you tried using S3 levelling? S4 will try and warp the bed out of plane (so will try and bend your build plate), but S3 will only make in-plane adjustments. That might help narrow down where your issue lies?

Phaedrux

@kcress said in Mesh Confusion:

The third faulted refusing to do a tram calculation because the error exceeded my 5mm limit. (Whole sequence has been repeated several times with a fault eventually after 3 or 4 trammings.)

Then something is definitely wrong if it's getting worse after each run. The order of the points in bed.g don't matter, but the order of the points in M671 must match the order of the motors in M584.

You must use the M671 command to define the X and Y coordinates of the leadscrews. The M671 command must come after the M584 command and must specify the same number of X and Y coordinates as the number of motors assigned to the Z axis in the M584 command; and these coordinates must be in the same order as the driver numbers of the associated motors in the M584 command. The M671 command must also come after any M667 or M669 command.

https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors

If you error is increasing after repeated runs of bed.g then I think your error lies in the order of M671.

kcress

@Robert: Yes tried your order. No obvious change.
Tried several different orders all with worse, even E-Stop pounding worse.

@engikeneer: Have not tries S3 since my bed is 3/8" plate aluminum. Only the gantry is Z on all four corners.

Also this makes me hesitate:
NOTE: From RepRapFirmware version 1.09 to 3.01-RC4, the number of factors may be 3, 4 or 5 when doing old-style auto bed compensation on a Cartesian or CoreXY printer. This form of bed compensation has been removed in RRF 3.01-RC5 and later.

@phaedrux To be clear, the values in M671 are supposed to be the physical mm locations of the actual gantry posts regardless of the head's ability to never make it to those points right?

Please check me here. Given the Z drives are 2,3,4,5 exactly as depicted in the square below. And, are in numeric order. Front LEFT is (0,0) Isn't my M671 correct?

M671 X-60.0:-60.0:460:460 Y-30.0:470.0:470.0:-30.0 S20   ; Z belts at 4 corners where the slides are
; --- drive map ---
;    _______
;   | 3 | 4 |
;   | ----- |
;   | 2 | 5 |
;    -------
;     FRONT

How can I drive the z motors independently of everything else to test their channel # and positions?

I made a MACRO to probe the 4 corners and only report the 4 values. The numbers repeat within a few 0.001mm.

engikeneer

@kcress Im not sure on that Wiki quote, I think that's referring to an old version of mesh compensation via G30 commands, but might be wrong. I know it definitely works in both 2.05.1 and 3.3.0 with S3 on my machines!
I also think I may have been wrong on the S3... from the independent bed levelling page:

The value of the S parameter on the final G30 command in bed.g must equal the number of Z motors

If you haven't already, you can run with S-1 and it will just report the measurements, not make the changes

kcress

@engikeneer Hi!
That's right the S now has to equal the number of Z motors. Thanks for reminding me.

As I mentioned the MACRO I whipped up? That's the G30 with S-1. Works well!

kcress

Well no one could tell me how to just drive a specific stepper output...

So, I decided to simply de-allocate three of the Z motors at a time in the M584 line of the config.g and do a Z move of the remaining one after an M564 H0 to allow un-homed movements. SMALL moves!

Doing that I could see which of the 4 Z motors was actually moving as compared to which one I thought should be moving.

Turned out instead of:

; --- drive map ---
;    _______
;   | 3 | 4 |
;   | ----- |
;   | 2 | 5 |
;    -------
;     FRONT

I actually had:

; --- drive map ---
;    _______
;   | 5 | 4 |
;   | ----- |
;   | 2 | 3 |
;    -------
;     FRONT

Which utterly screwed up everything causing the incrementing LR corner error and decrementing RF corner error with each G32 command. The errors even accelerated as with each subsequent G32 the error was greater demanding greater yet miscorrections

I'd traced all the cables manually but accidentally swapped those two even writing which Z motor they were(n't) on the cables.

I swapped those two on the 6HC and then ran HOME ALL and then consecutive G32s.

12/28/2021, 3:06:34 AM G32
Leadscrew adjustments made: -0.757 -0.154 1.087 -1.036, points used 4, (mean, deviation) before (0.024, 0.619) after (-0.000, 0.000)

12/28/2021, 3:07:28 AM G32
Leadscrew adjustments made: 0.099 0.146 0.462 0.296, points used 4, (mean, deviation) before (0.286, 0.104) after (-0.000, 0.000)

12/28/2021, 3:08:30 AM G32
Leadscrew adjustments made: 0.015 0.026 0.055 0.039, points used 4, (mean, deviation) before (0.038, 0.011) after (-0.000, 0.000)

12/28/2021, 3:21:13 AM G32
Leadscrew adjustments made: 0.007 0.005 0.006 0.006, points used 4, (mean, deviation) before (0.006, 0.001) after (0.000, 0.000)

Dang, what a struggle that was.
I do like the results! I appreciate only 0.0003" errors!!

So the lesson with 4 Z motors is this:

If, with repeated G32 (bed.g) runs any one corner increases its error positively while any other corner simultaneously has an increasingly negative error electrically swap those two corner's Z motors.

Solved Mesh Confusion

Robert J.

Robert J.