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

    Using G30 S0 inside homez.g fails

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    7
    17
    469
    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.
    • gloomyandyundefined
      gloomyandy @Ralms
      last edited by

      @Ralms said in [Bug] Using G30 S0 inside homez.g fails:

      Error: in file macro line 5: G1: insufficient axes homed

      The error you are seeing is being reported as being with a G1 command, not with a G30 command. Probably this line in your homez.g file:

      G1 X{var.bedCenterX} Y{var.bedCenterY} F5000
      

      This almost certainly means that for some reason when you are running the homez.g macro your X and/or Y axis has not been homed correctly. You should probably check your X and Y homing files (and possibly homeall.g) to understand why they are not working.

      1 Reply Last reply Reply Quote 0
      • Ralmsundefined
        Ralms @jay_s_uk
        last edited by

        @jay_s_uk said in [Bug] Using G30 S0 inside homez.g fails:

        @Ralms you're using G30 incorrectly
        it should be a single G30 with no other parameters
        There are lots of us that don't have Z endstops and only use a probe.
        I suggest you revisit the information about G30 in the gcode reference manual https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g30-single-z-probe

        I'm not using G30 incorrectly, I know the documentation and I've read it like 5 times troubleshooting this.
        It says

        G30, G30 S0 or G30 S-4 or lower are just normal probes. When the probe is triggered, sets the Z coordinate to the probe trigger height.

        and as any other configuration in RepRap, you can either let it use the defaults or be specific, I'm being specific here.

        Still, I've tested with G30 only, same error.

        @gloomyandy said in [Bug] Using G30 S0 inside homez.g fails:

        @Ralms said in [Bug] Using G30 S0 inside homez.g fails:

        Error: in file macro line 5: G1: insufficient axes homed

        The error you are seeing is being reported as being with a G1 command, not with a G30 command. Probably this line in your homez.g file:

        G1 X{var.bedCenterX} Y{var.bedCenterY} F5000
        

        This almost certainly means that for some reason when you are running the homez.g macro your X and/or Y axis has not been homed correctly. You should probably check your X and Y homing files (and possibly homeall.g) to understand why they are not working.

        It's not, the printer executes this G1 command and stops only after when is about to run G30. I've tested this.
        Also, at this point both X and Y are homed, so this G1 command should be valid regardless.

        Lastly, doesn't explain me running "G30 S0" on the console executing and throwing the error on itself.
        What I suspect is happening, is G30 calling G1 itself internally or something around those lines.

        @gloomyandy @jay_s_uk To reduce any further discussion on your arguments, I've went ahead and
        empty my homez.g, having only the "G30", as such:

        ; homez.g
        ; called to home the Z axis
        G30
        

        Literally, nothing else and it fails anyway with the same error.

        @dc42 Could you please confirm if this is in fact a bug or some nuance? thank you

        jay_s_ukundefined chrishammundefined 2 Replies Last reply Reply Quote 0
        • jay_s_ukundefined
          jay_s_uk @Ralms
          last edited by

          @Ralms you can't use X and Y coordinates in a G30 without a P value...

          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

          Ralmsundefined 1 Reply Last reply Reply Quote 0
          • chrishammundefined
            chrishamm administrators @Ralms
            last edited by

            @Ralms I highly doubt there is something wrong with G30. Do you have a deployprobe.g and/or retractprobe.g? We also need to know what kind of probe you have configured.

            Duet software engineer

            Ralmsundefined 1 Reply Last reply Reply Quote 0
            • Ralmsundefined
              Ralms @jay_s_uk
              last edited by

              @jay_s_uk said in [Bug] Using G30 S0 inside homez.g fails:

              @Ralms you can't use X and Y coordinates in a G30 without a P value...

              It's irrelevant, I just showed you that running G30 without ANYTHING ELSE, also fails....

              jay_s_ukundefined droftartsundefined 2 Replies Last reply Reply Quote 0
              • jay_s_ukundefined
                jay_s_uk @Ralms
                last edited by

                @Ralms ok, good luck then.
                Works ok for me here with 3.5.2

                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
                • Ralmsundefined
                  Ralms @chrishamm
                  last edited by

                  @chrishamm said in [Bug] Using G30 S0 inside homez.g fails:

                  @Ralms I highly doubt there is something wrong with G30. Do you have a deployprobe.g and/or retractprobe.g? We also need to know what kind of probe you have configured.

                  Well, I stand corrected, with you asking about deployprobe.g I remembered that I had some old draft gcode there and was the source of the error.
                  Removing the gcode from that file, allowed G30 to execute.

                  Still, doesn't explain why G30 will execute when called from the Console, ignoring an error at deployprobe.g.
                  Which is concerning, as it leaves the possibility of having the printer probe the bed without the probe being ready.

                  Regarding your question, about the probe, I forgot to share it but, essentially its a Klicky probe, running as type 8 due to being wired on the 1TL.

                  M558 P8 C"^121.io2.in" H5 F200:100 K0 T2000 
                  

                  @jay_s_uk Just to finish on your insistence in how I was running G30.
                  Running any of the mentioned configurations for G30 works and probes the bed successfully, that being G30, G30 S0and G30 S0 Xnnn Ynnn Z-9999.
                  However, specifying S0 parameter will execute anyway, probe the bed and set Z, however throws error Error: Number of calibration factors (0) not equal to number of leadscrews (4).
                  The same thing can be said for the parameters X, Y and Z, they are all just ignored, but return no error.

                  So yes, you were right that S, X, Y and Z parameters should not be used with G30 in this scenario but they were not the source of the issue, as I showed that even running without them would fail anyway.

                  1 Reply Last reply Reply Quote 0
                  • droftartsundefined
                    droftarts administrators @Ralms
                    last edited by

                    @Ralms Thanks for reporting this. I can confirm that G30 S0 does seem to be interpreted by the firmware as having a P parameter, and causes the error messages, even though the actual probing/homing completes successfully. I'll raise an issue to get this fixed, as G30, G30 S0 and G30 S-4 and lower should be synonymous.

                    For now, don't use G30 S0 for homing, or S0 without a P parameter, until this is fixed, to avoid the error message. Use G30 on it's own.

                    @Ralms said in [Bug] Using G30 S0 inside homez.g fails:

                    So yes, you were right that S, X, Y and Z parameters should not be used with G30 in this scenario but they were not the source of the issue, as I showed that even running without them would fail anyway.

                    I think the code in your deployprobe.g was probably unhoming the X and/or Y axes. Homing by probing in Z (as opposed to homing Z by hitting an endstop) requires X and Y to be homed. This caused the initial 'Error: in file macro line 5: insufficient axes homed' message.

                    Ian

                    Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

                    Ralmsundefined 1 Reply Last reply Reply Quote 0
                    • Ralmsundefined
                      Ralms @droftarts
                      last edited by

                      @droftarts Thanks for confirming.

                      The issue I had in my deployprobe.g was that I was trying to raise the gantry in absolute mode without having Z homed yet.
                      The goal of raising it is to avoid the probe hitting the bet when its attached.

                      Regarding G30, yeah, I will be using it without any parameter, its achieving the same end-goal, so I'm ok with it.

                      I just hope that someone doesn't get caught off-guard by G30 ignoring failures in deployprobe.g when called from the console, as it could mean the probe is not even deployed/attached and than the printer rams the hotend into the bed waiting for a trigger.
                      This is a very niche scenario and would require the probe to be setup incorrectly (normally open instead of the more reliable normally closed and opens on trigger), but still, its a possibility.

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

                        @Ralms note that when you call a homing file it first flags the axis as unhomed. My guess is when you did it from command line you had already homed the z axis?

                        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

                        Ralmsundefined 1 Reply Last reply Reply Quote 0
                        • Ralmsundefined
                          Ralms @engikeneer
                          last edited by

                          @engikeneer said in Using G30 S0 inside homez.g fails:

                          @Ralms note that when you call a homing file it first flags the axis as unhomed. My guess is when you did it from command line you had already homed the z axis?

                          When calling from the console, is just doing G30.
                          G30 only resets the Z axis and doesn't touch X or Y.
                          And yes, before calling G30 from the console, I already have the X and Y homed and with the probe in place.

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

                            @Ralms so basically, when you called G30 from console, Z was already homed, so the problematic G1 line to move an unhomed axis in your deployprobe.g wasn't an issue? But when calling homez.g with just a G30 in it, the z axis is marked as unhomed before deployprobe.g is called and hence you got the error. Your problematic command was to move z anyway so x and y don't come into it.

                            My point is that I think the behaviour you're seeing there is fully expected and 100% explainable

                            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

                            Ralmsundefined 1 Reply Last reply Reply Quote 0
                            • Ralmsundefined
                              Ralms @engikeneer
                              last edited by

                              @engikeneer said in Using G30 S0 inside homez.g fails:

                              @Ralms so basically, when you called G30 from console, Z was already homed, so the problematic G1 line to move an unhomed axis in your deployprobe.g wasn't an issue? But when calling homez.g with just a G30 in it, the z axis is marked as unhomed before deployprobe.g is called and hence you got the error. Your problematic command was to move z anyway so x and y don't come into it.

                              My point is that I think the behaviour you're seeing there is fully expected and 100% explainable

                              You miss understood.
                              Z is never homed in any of the scenarios I've mentioned (doing Home Z in the UI or calling G30 in the console), only X and Y are.

                              So yes, my G1 move in the deployprobe.g was a problem always as it was trying to move Z20.

                              The issue I'm raising now, is that G30 will execute from the console, even if deployprobe.g fails, it just ignores it and that should never happen.

                              oliofundefined droftartsundefined 2 Replies Last reply Reply Quote 0
                              • oliofundefined
                                oliof @Ralms
                                last edited by

                                @Ralms if you want to retain the clearing move on the z axis, you could do an unhinged move like this

                                G91 ; relative moves
                                G1 Z10 H2 ; move up 10mm
                                G90; absolute moves 
                                

                                <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                                1 Reply Last reply Reply Quote 0
                                • droftartsundefined
                                  droftarts administrators @Ralms
                                  last edited by

                                  @Ralms said in Using G30 S0 inside homez.g fails:

                                  The issue I'm raising now, is that G30 will execute from the console, even if deployprobe.g fails, it just ignores it and that should never happen.

                                  G30 works from the console or from within a macro, whether the Z axis is homed or not. The X and Y axes must be homed. When G30 is called, it will run deployprobe.g if the probe type requires it. When and why might deployprobe.g fail, and how would it know if deployprobe.g has failed? If running G30 from the console, it could possibly be too low to fully deploy, eg BLTouch, or off the bed, but I'd say this was operator error rather than the firmware's fault. You could have a check in deployprobe.g for current Z height, if it is below say 2mm, or if the axis is unhomed, move up 5mm. The stock homez.g from the configuration tool moves the Z axis up 5mm before homing to avoid this.

                                  Ian

                                  Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

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