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

    G53 command

    Scheduled Pinned Locked Moved
    Duet Hardware and wiring
    5
    43
    5.4k
    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.
    • dc42undefined
      dc42 administrators
      last edited by

      Great, thanks. I'll make G2 and G3 ignore G53.

      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

      1 Reply Last reply Reply Quote 0
      • Danalundefined
        Danal @timcurtis67
        last edited by Danal

        @timcurtis67 said in G53 command:

        @dc42 said in G53 command:

        G53 does cause the WCS to be ignored, but not the tool offsets. Is there anything in the NIST standard or other documentation that says that G53 should cause tool offsets to be ignored too?

        Yes G53 should only read true Machine zero's without any compensations. So you can return to certain positions for fixturing or tool changes. But it shouldn't cancel any compensations though.

        Tool offsets ARE part of the concept of a "Control Point". Put Simply G53 internal calculations do include tool offsets.

        NIST:

        2.1.2.3 Controlled Point
        The controlled point is the point whose position and rate of motion are controlled. When the tool length offset is zero (the default value), this is a point on the spindle axis (often called the gauge point) that is some fixed distance beyond the end of the spindle, usually near the end of a tool holder that fits into the spindle. The location of the controlled point can be moved out along the spindle axis by specifying some positive amount for the tool length offset

        I believe Duet/RepRap is already behaving correctly here... but have not personally verified.

        Delta / Kossel printer fanatic

        mwintermundefined 1 Reply Last reply Reply Quote 0
        • timcurtis67undefined
          timcurtis67 @dc42
          last edited by

          @dc42 said in G53 command:

          G53 does cause the WCS to be ignored, but not the tool offsets. Is there anything in the NIST standard or other documentation that says that G53 should cause tool offsets to be ignored too?

          I personally have never used a G53 coordinate to do arc moves in my 30+ years of programming/operating CNC machines.

          It's usually for moves to reference moves with G0's but could be used with G1's as well. I can't see any reason to use it for full motion tool paths.

          1 Reply Last reply Reply Quote 0
          • mwintermundefined
            mwinterm
            last edited by

            Same here, G53 is only used to end up in certain hardware related positions for tool change, lubrication.... So no need for G2 and G3 and never seen so far that it works with G2 or G3.

            @dc42 : Thank you very much for fixing this. Please let me know as soon as you have something on Github I can pull from.

            Regards,
            Marc

            1 Reply Last reply Reply Quote 0
            • mwintermundefined
              mwinterm @Danal
              last edited by

              Tool offsets ARE part of the concept of a "Control Point". Put Simply G53 internal calculations do include tool offsets.

              NIST:

              2.1.2.3 Controlled Point
              The controlled point is the point whose position and rate of motion are controlled. When the tool length offset is zero (the default value), this is a point on the spindle axis (often called the gauge point) that is some fixed distance beyond the end of the spindle, usually near the end of a tool holder that fits into the spindle. The location of the controlled point can be moved out along the spindle axis by specifying some positive amount for the tool length offset

              I believe Duet/RepRap is already behaving correctly here... but have not personally verified.

              I can't read it out of this that G53 should include tool offsets and neither on Heidenhain, nor on Sinumerik or Haas I have seen this being the case (for Haas you can check the youtube video I linked further up). It just would not work for tool change which is the most common use of G53 I'm aware of...

              timcurtis67undefined Danalundefined 2 Replies Last reply Reply Quote 0
              • timcurtis67undefined
                timcurtis67 @mwinterm
                last edited by

                @mwinterm said in G53 command:

                Tool offsets ARE part of the concept of a "Control Point". Put Simply G53 internal calculations do include tool offsets.

                NIST:

                2.1.2.3 Controlled Point
                The controlled point is the point whose position and rate of motion are controlled. When the tool length offset is zero (the default value), this is a point on the spindle axis (often called the gauge point) that is some fixed distance beyond the end of the spindle, usually near the end of a tool holder that fits into the spindle. The location of the controlled point can be moved out along the spindle axis by specifying some positive amount for the tool length offset

                I believe Duet/RepRap is already behaving correctly here... but have not personally verified.

                I can't read it out of this that G53 should include tool offsets and neither on Heidenhain, nor on Sinumerik or Haas I have seen this being the case (for Haas you can check the youtube video I linked further up). It just would not work for tool change which is the most common use of G53 I'm aware of...

                The Fanuc and Mitsubishi controls do not add tool comp to G53 either. It's a true position of each axis based on the true machine home position without any tool comps.

                1 Reply Last reply Reply Quote 0
                • Danalundefined
                  Danal @mwinterm
                  last edited by Danal

                  @mwinterm Hmmm... I very strongly agree that G53 arguments are "machine coordinates", with absolutely no offsets of any kind. Nothing else makes sense to the operations that occur on real machines, as you've pointed out.

                  I also agree this is shown in the HAAS vid, right around 1:28.

                  The "Hmmm...." is because of the odd phrasing in the NIST standard. Let me poke around a bit more.

                  Delta / Kossel printer fanatic

                  1 Reply Last reply Reply Quote 0
                  • Danalundefined
                    Danal
                    last edited by

                    Well, I can't find anything in the standard. However, the standard is an attempt to describe the interpreter itself, and the interpreter is still available. Old, and in a very old "coding style"... but still out there.

                    Reading the old RS274NGC source, tool offsets are not applied when G53 is (non-modally) active.

                    As we all said... 🙂

                    Delta / Kossel printer fanatic

                    1 Reply Last reply Reply Quote 0
                    • mwintermundefined
                      mwinterm
                      last edited by

                      @dc42: This post kind of also relates to the G0/G1 discussion I raised in another post (https://forum.duet3d.com/topic/7728/g0-vs-g1-movement). For the G53 to really function correctly for tool-changes etc. bed compensation also needs to be disabled for G53 G0... . I'm not aware if the standards say anything regarding G53 G1... but having G53 G0 ignoring all compensations (WCS, Tool & Bed) and having G53 G1 ignoring only WCS and Tool but keeping bed compensation in could give all the options.

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

                        Thanks to all of you for the references. I made a change ni 2.02RC5 so that tool offsets are not applied when G53 is active.

                        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

                        1 Reply Last reply Reply Quote 0
                        • mwintermundefined
                          mwinterm
                          last edited by

                          @dc42 Thanks a lot. Already built and tested it (even though not yet extensively) but everything seems to work fine 👍 👍 👍 🙂

                          1 Reply Last reply Reply Quote 0
                          • mwintermundefined
                            mwinterm
                            last edited by

                            @dc42 : ...just noticed that there is already a built RC5 available... However I saw that in the release notes you refer to a modification of G54 instead of G53.... small typo but could be confusing as G54 (i.e. WCS) should for sure take tool offsets into account....

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

                              @mwinterm said in G53 command:

                              @dc42 : ...just noticed that there is already a built RC5 available... However I saw that in the release notes you refer to a modification of G54 instead of G53.... small typo but could be confusing as G54 (i.e. WCS) should for sure take tool offsets into account....

                              It should have read G53. I have corrected it.

                              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

                              1 Reply Last reply Reply Quote 0
                              • mwintermundefined
                                mwinterm
                                last edited by

                                @dc42 I detected another behavior of G53 which I believe is not correct. If G91 is selected G53 also makes relative moves which I believe is not correct. As outlined in earlier posts G53 is typically used to move to fixed machine position e.g. for tool change... This should happen independently of if G90 or G91 is selected.

                                Catalin_ROundefined 1 Reply Last reply Reply Quote 0
                                • Catalin_ROundefined
                                  Catalin_RO @mwinterm
                                  last edited by

                                  @mwinterm I don't see why G53 should not allow G91! Currently used coordinate system and relative vs. absolute moves are two completely different things. I can imagine quite a few scenarios where relative moves are needed even with G53.

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

                                    The NIST standard appears to be silent on whether moves are always absolute when G53 is used, or are affected by G91. Does anyone know what Fanuc, grbl or Smoothieware do?

                                    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

                                    1 Reply Last reply Reply Quote 0
                                    • timcurtis67undefined
                                      timcurtis67
                                      last edited by timcurtis67

                                      On my Fanuc machine (16i control) when I try a incremental (G91) move in G53 machine cord. the control doesn't move. It just ignores the command. No error, it just doesn't move. Where an absolute (G90) command moves as it should.

                                      I can't speak for all machine controls but for a majority of them (all of the ones I have run) the G53 work cord is not modal. Meaning if you need a move that needs to be carried out under the G53 machine cord, the G53 must be in the same line with the move. When the next move is executed the work cord resorts back to what ever work cord you are using.

                                      Example If I am running a program under a G55 work cord, And I want to go to a fixture reference point with G53 here would be my command - G0G90G53 X4.1 Y16.114.

                                      If the next line of my program is G0 X1.0 Y0.0 the machine will move to X1.0 Y0.0 position of G55 not G53. I would have to include the G53 in line same command to go to the machine cord X1.0 Y0.0.

                                      You can't really put the machine work cord in G53 and have it remain active until you call up a different work cord like G54 or G55. You can reference the G53 at anytime during your program operation by specifically calling it out in the line during the command.

                                      I can't say what smoothieboard or grbl does.

                                      Why would you need a G91 incremental move when referencing the machine work cord? Just curious?

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

                                        Thanks, Tim. G53 isn't modal in RRF either, so if only affects the remaining commands on the current line. However, RRF treats multiple G or M codes in a line as separate commands and executes them sequentially. So for RRF your example would have to be rewritten as either "G90 G53 G0 X4.1 Y16.114" or "G53 G90 G0 X4.1 Y16.114", or just "G53 G0 X4.1 Y16.114" if the movement mode is already absolute.

                                        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

                                        timcurtis67undefined 1 Reply Last reply Reply Quote 0
                                        • timcurtis67undefined
                                          timcurtis67 @dc42
                                          last edited by

                                          @dc42 said in G53 command:

                                          Thanks, Tim. G53 isn't modal in RRF either, so if only affects the remaining commands on the current line. However, RRF treats multiple G or M codes in a line as separate commands and executes them sequentially. So for RRF your example would have to be rewritten as either "G90 G53 G0 X4.1 Y16.114" or "G53 G90 G0 X4.1 Y16.114", or just "G53 G0 X4.1 Y16.114" if the movement mode is already absolute.

                                          Thanks for the info David.

                                          My next project is going to either be a cnc mill or cnc plazma cutter. I am in need of both 😀

                                          Of course I will be using a DuetWifi to control it.

                                          1 Reply Last reply Reply Quote 0
                                          • Danalundefined
                                            Danal
                                            last edited by Danal

                                            The standard is silent; pragmatic real world use speaks volumes.

                                            Consider trying to probe* for the corner of a fixture. Operator puts the probe "near" but "off of" the corner of the Xmin Ymin edge of the fixture. Probe now needs to repeatedly move Y+ (stop if probe contacts) and Y-, then slightly X+, then repeat. A linear rectangular grid search for the corner. This can only realistically be programmed (as a reusable script) with relative moves, and the human operator MUST have the results in G53 coordinate system to "know" where that fixture is for future use.

                                            Repeat for X.

                                            .

                                            * Non-CNC folk may only be familiar with Z probes. CNC machines often probe "sideways" with the bit itself as the probe. Metal to Metal contact, no switches or inductors or whatever. Just the bit, and the fixture or metal workpiece/stock about to be cut.

                                            Delta / Kossel printer fanatic

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