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

    V3.4 SBC - G32 not working correctly ??

    Scheduled Pinned Locked Moved
    General Discussion
    5
    17
    1.1k
    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.
    • jay_s_ukundefined
      jay_s_uk @Dr_Ju_Ju
      last edited by

      @dr_ju_ju you probably don't have the M584 mapping and M671 in the same order.
      Lets say you've mapped the Z motors clockwise starting front left, using drivers 0.2 to 0.5 respectively, M584 would look like M584 Z0.2:0.3:0.4:0.5
      The M671 should be in the same order. So M671 X0:0:300:300 Y0:300:0:300
      If you don't map them in the same order then G32 won't work

      Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

      Dr_Ju_Juundefined 1 Reply Last reply Reply Quote 0
      • Dr_Ju_Juundefined
        Dr_Ju_Ju @jay_s_uk
        last edited by

        @jay_s_uk

        Thanks Jay, but from my config.g. file in order:

        ; Axis Limits

        ; Z Motor Layout
        ; ----------- X-Y (A-B) Homing Position
        ; Z1 | Z2
        ; -----+-----
        ; Z0 | Z3
        ; 0,0 -----------
        ; Front

        M584 X0.0 ; set drive mapping X
        M584 Y0.1 ; set drive mapping Y
        M584 Z0.2:0.3:0.4:0.5 ; set drive mapping Z
        M584 E1.0 ; set drive mapping E (extruder on 3HC)

        M557 X5:295 Y5:295 P3 ; define G29 mesh probe grid

        M671 X-80:-80:380:380 Y-70:390:390:-70 S5 ; leadscrews at Front left, Rear left, Rear right and Front right, S - Maximum error allowed before system rejects, Note Motor Connections MUST Match

        So I think I have it the right order, the M671 mappings are outside of the bed area as they are the actual motor positions

        Julian,

        Old goat, learning new things….

        jay_s_ukundefined 1 Reply Last reply Reply Quote 0
        • jay_s_ukundefined
          jay_s_uk @Dr_Ju_Ju
          last edited by

          @dr_ju_ju I would also check that you've got the motors plugged in in the right order. The motor connections on the 6HC are in a funny order (see here https://forum.duet3d.com/topic/28388/only-one-driver-working/10?_=1652863946598)

          Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

          1 Reply Last reply Reply Quote 0
          • Dr_Ju_Juundefined
            Dr_Ju_Ju
            last edited by

            Jay,

            I flipped the printer over & re-checked the connections, and all is as it should be....Bed_View.jpg Motor_Conns.jpg

            The main reason I wanted to go back to v3.3.is that everything worked as expected, i.e. multiple G32 iterations, made things better not worse, The only physical changes have been to change the extruder to a Revo & setting the Precision Piezo to be under bed as opposed to extruder mounted, but both changes were successful.

            Julian,

            Old goat, learning new things….

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

              M566 X900.00 Y900.00 Z900.00:900.00:900.00:900.00 E120.00
              The Z jerk value should only be set a single time.

              Can you send M98 P"config.g" and report any errors?

              To roll back to 3.3 using an SBC you'd need to follow these steps.

              https://docs.duet3d.com/en/User_manual/Machine_configuration/DSF_RPi#downgrade-packages

              Is that what you tried?

              ; Z Axis
              ;G91                    ; relative positioning
              ;G1 H1 Z25 F1000        ; lift Z relative to current position
              G90                     ; absolute positioning
              G1 X150 Y150 F6000      ; Go to the bed centre & probe point and home the Z axis
              G1 H1 Z-99999 F1000       ; move Z down until the endstop is triggered
              G1 H0 Z25 F1000         ; lift Z 25mm
              G1 H1 Z-100 F400
              ; G30                     ; Calibrate Z-axis
              ; G92 Z0                  ; set Z position to axis minimum (you may want to adjust this)
              G1 H0 Z25 F6000         ; lift nozzle
              

              What Z endstop are you using here? Your config.g doesn't seem to show one configured.

              ; Z-Probe
              M558 P1 C"!^io6.in" H10 F500 R1 A3 S0.03 T5000                         ; set Z probe type to unmodulated and the dive height, speeds, pause inter point travel speed
              G31 P500 X0 Y0 Z0                                                      ; set Z probe trigger value, offset and trigger height
              
              ; Endstops
              M574 X2 S1 P"^io1.in"                                                  ; configure switch-type (e.g. microswitch) endstop for high end on X via pin ^io1.in
              M574 Y2 S1 P"^io2.in"                                                  ; configure switch-type (e.g. microswitch) endstop for high end on Y via pin ^io2.in
              M574 Z1 S2                                                             ; Configure Z to use Probe
              

              How are you setting the Z0 point? Have you tested the probe trigger height at the different points on the bed? Is it basically the same, or does it vary with position?

              Can you post your homing files?

              Z-Bot CoreXY Build | Thingiverse Profile

              Dr_Ju_Juundefined 1 Reply Last reply Reply Quote 0
              • Dr_Ju_Juundefined
                Dr_Ju_Ju @Phaedrux
                last edited by

                @phaedrux Thanks for your suggestions, to answer:

                I've set M566 command to a single value, not multiple for each motor, my bad.

                M98 just runs with no errors/output etc.

                Yes, I tried that method, and I also created another SD card (using Raspberry Pi Imager) with 3.3 from the original stable version, I downloaded last year. In both instances, the hardware was not recognised, so DWC service would not start...

                My homing files are attached, X & Y are ok but Z is still a "work in progress" till I can get repeatable
                HomeFiles.zip.txt

                I believe I've defined the Z endstop to be the Precision Piezo Probe (M558 command) and then selecting it using the M574 Z1 S2 command ?? Note: once again the G31 command will be "fine tuned" when things are stable.

                @phaedrux said in V3.4 SBC - G32 not working correctly ??:

                Have you tested the probe trigger height at the different points on the bed? Is it basically the same
                Yes, I'm using under bed piezo sensor and I get the same results no matter where I probe..

                And after making the changes to config.g (above), and re-running the "start up" macro, I still get the same results with worsening height maps on each iteration HeightMaps-new.zip.txt

                Julian,

                Old goat, learning new things….

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

                  @dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

                  Yes, I tried that method, and I also created another SD card (using Raspberry Pi Imager) with 3.3 from the original stable version, I downloaded last year. In both instances, the hardware was not recognised, so DWC service would not start...

                  In this case you may need to manually flash the board to 3.3 to get it in line with the Pi version. Either USB and Bossa, or place the required bin files on the SD card and send M997 to flash. This can be complicated by the change to a /firmware folder in 3.3 so you may need to place the files in both /firmware and /sys. Using Bossa and USB is a bit more straightforward. Can also be done from the Pi via command line bossac.

                  @dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

                  I believe I've defined the Z endstop to be the Precision Piezo Probe (M558 command) and then selecting it using the M574 Z1 S2 command ??

                  This is a very bizarre way to use a probe. M574 Z1 S2 is actually not necessary to use a probe for Z at all. S2 actually intended for axis other than Z where you may want to use a probe.

                  So yes you have a probe defined with M558 but your macro is using an endstop homing command for Z instead of G30 which you have commented out. When doing this I think you're skipping the entire G31 probe configuration, which is what's causing you problems.

                  G1 H1 Z-100 F400
                  ; G30                     ; Calibrate Z-axis
                  

                  So when you want to use the probe to home Z, you must use G30.

                  Z-Bot CoreXY Build | Thingiverse Profile

                  Dr_Ju_Juundefined 1 Reply Last reply Reply Quote 0
                  • Dr_Ju_Juundefined
                    Dr_Ju_Ju @Phaedrux
                    last edited by

                    @phaedrux

                    Yea, that's what I was thinking about re-flashing the firmware, but I didn't want to go down that route until I've exhausted everything else in trying to get the current 3.4 setup working.

                    Now I'm getting totally confused as per (https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_endstops) Firmware configuration paragraph, that is exactly how it should be configured (M574 Z1 S2)

                    I've re-enabled the G30 setting, but unless I've enabled the M574 setting I only get "Error: Failed to enable endstops" when trying to home the Z axis.

                    And still, after setting the above, the system still does not give a reliable/repeatable solution, and worsens through iterations.

                    Julian,

                    Old goat, learning new things….

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

                      @dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

                      Firmware configuration paragraph, that is exactly how it should be configured (M574 Z1 S2)

                      Sure, but to actually use the probe as a probe, you must use G30. You can remove the M574 Z1 S2 line entirely and still use G30 to home Z.

                      @dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

                      I've re-enabled the G30 setting, but unless I've enabled the M574 setting I only get "Error: Failed to enable endstops" when trying to home the Z axis.

                      This is likely because you still have the G1 H1 Z move to home the Z axis with an endstop seeking move. Comment that out. G1 H1 Z-100 F400

                      @dr_ju_ju said in V3.4 SBC - G32 not working correctly ??:

                      And still, after setting the above, the system still does not give a reliable/repeatable solution, and worsens through iterations.

                      I ask again: "Have you tested the probe trigger height at the different points on the bed? Is it basically the same, or does it vary with position?"

                      Z-Bot CoreXY Build | Thingiverse Profile

                      Dr_Ju_Juundefined 1 Reply Last reply Reply Quote 0
                      • Dr_Ju_Juundefined
                        Dr_Ju_Ju @Phaedrux
                        last edited by

                        @phaedrux Thanks for all your help...

                        After removing the M574, and additional Z move settings, the system now uses the probe as the end-stop correctly.

                        Yes, I have checked that the probe trigger heights are the same at various points on the bed..

                        But after all that, the system still does not give consistent results, and worsens through multiple iterations:

                        Console.txt

                        HeightMaps.zip.txt

                        Julian,

                        Old goat, learning new things….

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

                          worsens through multiple iterations

                          That almost always indicates the order of z drivers doesn't match the order of the defined positions.

                          Z-Bot CoreXY Build | Thingiverse Profile

                          Dr_Ju_Juundefined 1 Reply Last reply Reply Quote 0
                          • Dr_Ju_Juundefined
                            Dr_Ju_Ju @Phaedrux
                            last edited by

                            @phaedrux

                            Maybe getting somewhere....

                            To ensure that the Z motor mapping were/are correct, I plugged in each motor it turn, leaving the others unplugged, and ensured that only the appropriate motor moved.

                            I then re looked at the mappings in the config files etc. and all appeared to be ok. Re-ran the levelling loop with no change.

                            On a whim, I decided to change the defined positions of the Z motors using M671, from their true positions to the bed co-ordinates i.e.:

                            M671 X-80:-80:380:380 Y-70:390:390:-70 S10
                            to
                            M671 X0:0:300:300 Y0:300:300:0 S10

                            Re-running the bed levelling loop, after the update, produced a significant improvement in repeatability etc. console.txt

                            This then me thinks that either I didn't have the settings correct in the first place ?? or that the system doesn't like negative numbers ??

                            Julian,

                            Old goat, learning new things….

                            gloomyandyundefined 1 Reply Last reply Reply Quote 0
                            • gloomyandyundefined
                              gloomyandy @Dr_Ju_Ju
                              last edited by

                              @dr_ju_ju The coordinates you use in M671 should be the location of the pivot points of the bed support, this may or may not be the same as the location of the motors.

                              Dr_Ju_Juundefined 1 Reply Last reply Reply Quote 0
                              • Dr_Ju_Juundefined
                                Dr_Ju_Ju @gloomyandy
                                last edited by

                                @gloomyandy

                                my bad for not stating things correctly, within a few mm, i had configured the positions of the belts that raise/lower the Z axis as defined at https://docs.duet3d.com/User_manual/Reference/Gcodes, which are outside of the bed coordinates. for a Voron2.4 printer.

                                Julian,

                                Old goat, learning new things….

                                dc42undefined 1 Reply Last reply Reply Quote 0
                                • dc42undefined
                                  dc42 administrators @Dr_Ju_Ju
                                  last edited by

                                  @dr_ju_ju to check that G32 true bed levelling is working correctly, run G32 several times and see how the reported initial error changes. Ideally the reported initial error would be zero on the second iteration, because the first iteration will have levelled the bed. In practice it's more likely that the errors will have reduced (perhaps by 75%) but not been completely eliminated.

                                  If the reported errors increase, this usually means that you haven't defined the bed support coordinates in the M671 command in the same order as you declared the Z motors in the M584 command.

                                  If the errors diminish on each iteration but by less than 75% then it may mean that there is insufficient give in the coupling between the leadscrews and the bed for the bed to adopt the flat plane defined by the leadscrew positions.

                                  After running G32 one or more times, it's a good idea to do a single G30 probe at bed centre before using G29 to construct a height map.

                                  Duet WiFi hardware designer and firmware engineer
                                  Please do not ask me for Duet support via PM or email, use the forum
                                  http://www.escher3d.com, https://miscsolutions.wordpress.com

                                  Dr_Ju_Juundefined 1 Reply Last reply Reply Quote 0
                                  • Dr_Ju_Juundefined
                                    Dr_Ju_Ju @dc42
                                    last edited by

                                    @dc42 Thank you for the suggestion of running G30 (Z home) before running G29, as it now looks like I may be close to a workable solution...

                                    But that is only if I have M671 set, to the bed coordinates, if it is set to the motor/belt coordinates, then errors keep increasing i.e.

                                    Bed-Coords.zip.txt

                                    Belt-Coords-results.zip.txt

                                    Note that the bed is fixed, and only the XY gantry moves in the Z axis using four motors/belts.

                                    Julian,

                                    Old goat, learning new things….

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Unless otherwise noted, all forum content is licensed under CC-BY-SA