Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Mesh Confusion

    Scheduled Pinned Locked Moved Solved
    Tuning and tweaking
    4
    14
    682
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • kcressundefined
      kcress @Phaedrux
      last edited by

      @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?

      Phaedruxundefined 1 Reply Last reply Reply Quote 0
      • rjenkinsgbundefined
        rjenkinsgb
        last edited by

        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.
        
        

        Robert J.

        Printers: Overlord pro, Kossel XL+ with Duet 6HC and "Frankentron", TronXY X5SA Pro converted to E3D toolchange with Duet 6HC and 1LC toolboards.

        kcressundefined 1 Reply Last reply Reply Quote 0
        • kcressundefined
          kcress @rjenkinsgb
          last edited by

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

          rjenkinsgbundefined 1 Reply Last reply Reply Quote 0
          • rjenkinsgbundefined
            rjenkinsgb @kcress
            last edited by rjenkinsgb

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

            Robert J.

            Printers: Overlord pro, Kossel XL+ with Duet 6HC and "Frankentron", TronXY X5SA Pro converted to E3D toolchange with Duet 6HC and 1LC toolboards.

            engikeneerundefined 1 Reply Last reply Reply Quote 0
            • engikeneerundefined
              engikeneer @rjenkinsgb
              last edited by

              @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?

              E3D TC with D3Mini and Toolboards.
              Home-built CoreXY, Duet Wifi, Chimera direct drive, 2x BMG, 300x300x300 build volume
              i3 clone with a bunch of mods

              1 Reply Last reply Reply Quote 0
              • Phaedruxundefined
                Phaedrux Moderator @kcress
                last edited by

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

                Z-Bot CoreXY Build | Thingiverse Profile

                1 Reply Last reply Reply Quote 0
                • kcressundefined
                  kcress
                  last edited by

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

                  engikeneerundefined 1 Reply Last reply Reply Quote 0
                  • engikeneerundefined
                    engikeneer @kcress
                    last edited by

                    @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

                    E3D TC with D3Mini and Toolboards.
                    Home-built CoreXY, Duet Wifi, Chimera direct drive, 2x BMG, 300x300x300 build volume
                    i3 clone with a bunch of mods

                    kcressundefined 1 Reply Last reply Reply Quote 0
                    • kcressundefined
                      kcress @engikeneer
                      last edited by

                      @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!

                      kcressundefined 1 Reply Last reply Reply Quote 1
                      • kcressundefined
                        kcress @kcress
                        last edited by 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.

                        1 Reply Last reply Reply Quote 1
                        • Phaedruxundefined Phaedrux marked this topic as a question
                        • Phaedruxundefined Phaedrux has marked this topic as solved
                        • First post
                          Last post
                        Unless otherwise noted, all forum content is licensed under CC-BY-SA