• Tags
  • Documentation
  • Order
  • Register
  • Login
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.
  • undefined
    Danal
    last edited by 4 Jan 2019, 17:08

    To summarize:

    G53 is "absolute machine". G53 is non-modal. G53 is therefore only 'active' on the line where it appears.

    G54/5/... can be offset from absolute machine. They are modal. They stay active for all following lines until changed.

    When G90 is active, G0 or G1 move axis numbers specify a position in that active coordinate system, including G53, G54, G55...

    When G91 is active, G0 or G1 move axis numbers specify a position relative to the current position in that active coordinate system, including G53, G54, G55...

    Delta / Kossel printer fanatic

    1 Reply Last reply Reply Quote 0
    • undefined
      mwinterm
      last edited by 4 Jan 2019, 17:41

      @Danal sorry for being ignorant, but I don’t get it: A machine can only have one physical position. Assuming that we don’t deal with rotated coordinate systems which coordinate system you are in is only relevant for G90. In G91 mode coordinate systems are completely irrelevant as the move is just added to the current physical position independent of in which coordinate system they are represented i.e. the selected coordinate system only affects the numbers displayed but not the real position.
      Please help me if I miss something here....

      undefined 1 Reply Last reply 4 Jan 2019, 19:04 Reply Quote 0
      • undefined
        mwinterm
        last edited by 4 Jan 2019, 18:10

        Sorry, I correct my statement. If dealing with non-Cartesian systems like in hang printers or 4- and 5-axis systems relative G53 moves could make sense.
        However still wondering how Haidenhein an Siemens deal with the problem...

        PS: is a G90 or G91 called from within a macro still active after the macro is finished? If so is there a way how the G90/91 mode active before the start of a macro could be re-established after the macro... this would be another way to deal with the issue....

        undefined 1 Reply Last reply 4 Jan 2019, 18:29 Reply Quote 0
        • undefined
          dc42 administrators @mwinterm
          last edited by 4 Jan 2019, 18:29

          @mwinterm said in G53 command:

          PS: is a G90 or G91 called from within a macro still active after the macro is finished? If so is there a way how the G90/91 mode active before the start of a macro could be re-established after the macro... this would be another way to deal with the issue....

          The G90/G91 state just prior to the macro being executed is restored when it ends. So you can safely use G90 and G91 within macros.

          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

          undefined 1 Reply Last reply 7 Jan 2019, 10:54 Reply Quote 0
          • undefined
            Danal @mwinterm
            last edited by Danal 1 Apr 2019, 19:04 4 Jan 2019, 19:04

            @mwinterm said in G53 command:

            @Danal sorry for being ignorant, but I don’t get it: A machine can only have one physical position. Assuming that we don’t deal with rotated coordinate systems which coordinate system you are in is only relevant for G90. In G91 mode coordinate systems are completely irrelevant as the move is just added to the current physical position independent of in which coordinate system they are represented i.e. the selected coordinate system only affects the numbers displayed but not the real position.
            Please help me if I miss something here....

            The results of what you are saying are identical to the results of what I'm saying.

            1. The way the NIST standard phrases it:

            The machine is in a coordinate system, such as G54. A G1 move is executed. The numbers in the axis words of G1 are "applied" (either directly for G90 or via math for G91) to the starting position to derive an ending position in the active coordinate system. This position in the active coordinate system is then offset (more math) to the absolute (aka G53) physical position desired, and the machine is moved there.

            Your phrasing:

            The machine starts at an absolute machine position. A G1 is executed. The numbers in the axis words of that G1 are "applied" (directly for G90, with math for G91) to the machine starting position to derive a machine ending position. The machine moves there.

            Same thing... same results... except the first phrasing is actually how the NIST interpreter works (the source code for the interpreter is available).

            The one place where these are different is the reason they do the more elaborate sequence. It is perfectly legal in G-Code to change the offset of the currently active coordinate system, WITHOUT physically moving the machine. This really only affects the next move when G90 is active... Nonetheless, writing the code to ALWAYS do the same calculations (after the G90/G91 step of the calculations) is simply more "internally consistent" in the code itself, thus potentially avoiding obscure bugs.

            Delta / Kossel printer fanatic

            1 Reply Last reply Reply Quote 0
            • undefined
              Danal
              last edited by 4 Jan 2019, 19:05

              For G91, the way we are both describing it is "start, math with G1 numbers, move".

              You are assuming it all starts with the G53 absolute, and the code is actually written to start with "currently active" coordinate system numbers, for internal consistency reasons with the way that G90 must work.

              Delta / Kossel printer fanatic

              1 Reply Last reply Reply Quote 0
              • undefined
                mwinterm @dc42
                last edited by 7 Jan 2019, 10:54

                @dc42 Thanks for the hint. That helps...

                PS: ...is my assumption right that the behavior is the same for *.g files in the system directory?

                undefined 1 Reply Last reply 7 Jan 2019, 12:42 Reply Quote 0
                • undefined
                  dc42 administrators @mwinterm
                  last edited by dc42 1 Jul 2019, 12:43 7 Jan 2019, 12:42

                  @mwinterm said in G53 command:

                  @dc42 Thanks for the hint. That helps...

                  PS: ...is my assumption right that the behavior is the same for *.g files in the system directory?

                  No. So if you print a file that doesn't have M82 or M83 near the start, then the result could depend on whether the previous file you printed contained M82 or M83. The initial M82/M83 state will be the same as at the end of config.g.

                  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
                  • undefined
                    mwinterm
                    last edited by mwinterm 1 Jul 2019, 14:26 7 Jan 2019, 14:24

                    @dc42 : Starting a new program is typically no problem as CNC program always explicitly contain G90 or G91 already at the beginning.
                    My specific problem at hand if I have a stall detected I want to re-home during a program. So I have in rehome.g
                    M24
                    G28
                    M25
                    where G28 again calls homeall.g which contains a G91 at the beginning and a G90 at the end. Assuming the program was running in G91 before the stall this would generate a problem...

                    PS: Could the problem be hacked around by call a Macro from the homeall.g?

                    1 Reply Last reply Reply Quote 0
                    • undefined
                      dc42 administrators
                      last edited by dc42 1 Jul 2019, 19:21 7 Jan 2019, 19:20

                      You shouldn't need the M24 and M25 commands and I suspect they won't work anyway, but you might want to lift Z a little at the start and lower it at the end of rehome.g. The G90/91 and M82/83 status and feed rate will be preserved automatically.

                      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

                      undefined 1 Reply Last reply 7 Jan 2019, 20:44 Reply Quote 0
                      • undefined
                        mwinterm @dc42
                        last edited by 7 Jan 2019, 20:44

                        @dc42: Normally M25 calls the pause.g and M24 resume.g if present. In there is my spindle stop / retract and my spindle start / re-approach code. However the pause command called by M915 seems not to execute those procedures (that is why I called them explicitly which as you predicted didn't work either). Is there a reason for this?

                        1 Reply Last reply Reply Quote 0
                        • undefined
                          dc42 administrators
                          last edited by 8 Jan 2019, 13:12

                          On a 3D printer it isn't necessarily appropriate to run the full pause/resume routine. If you want to run the full routine on your CNC then you could put M98 Ppause.g at the start of your rehome.g file, and M98 Presume.g at the end.

                          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
                          • undefined
                            mwinterm
                            last edited by 8 Jan 2019, 14:37

                            @dc42: ok, thank you!

                            PS: ...regarding G53 I checked Heidenhain and Sinumerik.

                            • Heidenhain uses G53 in a different context (selecting a WCS from a table of WCS). However the equivalent to our G53 are M91/M92. The allow for relative positioning. Tool length and other compensations are not respected. They are used for positioning the machine on specific positions on their axis as for tool change, etc.

                            Sinumerik: Seems to use G53 just a another predefined coordinate system from the machine even including tool compensation. By adding D0 tool compensation can be deactivated tough. However for the purpose of tool change Sinumerik provides the G74/G75 commands. But they are used a bit differently as you can predefine machine specific points than then are selected with these commands.

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