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

    RRF 3.4 Beta 7 | Tool-Offsets Issue

    Scheduled Pinned Locked Moved
    General Discussion
    8
    21
    1.3k
    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 @CR3D
      last edited by

      @cr3d did you read this item from the RRF 3.4 upgrade notes:

      • After changing tool, RRF no longer moves the new tool head to the coordinates at which the old tool head was at when the Tn command was actioned. In most situations this should not matter, because GCode generators usually generate commands to move to the correct XYZ position after generating a Tn command. Usually, they restore XY before Z. However, Cura does it the other way round, which risks dragging the tool head across the print. Therefore when using Cura, or in any other situations in which you want to restore the old behaviour, we suggest you add command G1 R2 X0 Y0 Z2 Fxxx followed by G1 R2 Z0 Fxxx to the end of your tpost#.g files, if you don't already use those or similar commands.

      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

      CR3Dundefined 2 Replies Last reply Reply Quote 1
      • CR3Dundefined
        CR3D @dc42
        last edited by

        @dc42 ok thank you!

        I overread this section... in this printer series we tested it today there wasnยดt this section in the tpost.g

        if that was the solution, i take everything back and claim the opposite!

        Thank you for your prompt reply ๐Ÿ™‚

        Regards Christian

        Christian from CR-3D
        Homepage:
        www.cr-3d.de

        Facebook:
        https://www.facebook.com/cr3d.official

        Our Discord Server
        https://discord.gg/SxRaPNuRdA

        Thingiverse Profile:
        https://www.thingiverse.com/cr-3d_official/about

        sonderzugundefined 1 Reply Last reply Reply Quote 2
        • sonderzugundefined
          sonderzug @CR3D
          last edited by

          @cr3d
          Hi Christian,

          one thing that came to my mind, which you might want to check - are you using firmware retraction and different z-hop heights in M207? This seems to be a problem with my setup (E3D Toolchanger), especially when trying to use G10/G11 as a retract/unretract move at tool change.
          I have to say though that my machine is still running at an older 2.x version of RRF, so I'm not sure what might have changed, especially in regards to the behaviour of RRF 3.4 and onwards like David posted before.

          best, Niklas

          1 Reply Last reply Reply Quote 0
          • CR3Dundefined
            CR3D @dc42
            last edited by

            @dc42 said in RRF 3.4 Beta 7 | Tool-Offsets Issue:

            @cr3d did you read this item from the RRF 3.4 upgrade notes:

            • After changing tool, RRF no longer moves the new tool head to the coordinates at which the old tool head was at when the Tn command was actioned. In most situations this should not matter, because GCode generators usually generate commands to move to the correct XYZ position after generating a Tn command. Usually, they restore XY before Z. However, Cura does it the other way round, which risks dragging the tool head across the print. Therefore when using Cura, or in any other situations in which you want to restore the old behaviour, we suggest you add command G1 R2 X0 Y0 Z2 Fxxx followed by G1 R2 Z0 Fxxx to the end of your tpost#.g files, if you don't already use those or similar commands.

            Sorry @dc42 DC42 that I still have to take up the topic, but what you claim here is simply not the case! The whole topic always worked without any problems before the update and since the update the new tool has moved exactly to the old position! This leads to many collisions and should be restored to the way it was before as soon as possible.

            The required command is in tpost.g.

            ;wait for tool 1 heaters to reach operating temperature
            M116 P1 S5
            
            ;go to
            G1 X328 Y65 F50000 
            
            ;unretract
            G11
            
            ;clean
            M98 P"clean1.g"
            
            ;PCF fan on
            M106 R2
            
            G1 R2 X0 Y0 Z2    ; restore position 2mm above
            G1 R2 X0 Y0 Z0    ; restore position
            

            In the pictures you can see the left tool in front of the tool change to X=0mm and the right one in park position.

            PXL_20220825_044836503.jpg

            After the tool change, T1 (because it moves to the old position of T0) crashes into T0.

            PXL_20220825_044855401.jpg

            He also makes unnecessary movements during the print. The principle may work for tool changers, but not for IDEX printers.

            It works so far, even if the print head is always somehow in the middle of the print bed before the tool change. But it often happens that this is also in the extreme positions and then there is a crash.

            Please help or a solution.

            As I said before all the changes, everything was perfect and it worked. ๐Ÿ™‚

            Christian from CR-3D
            Homepage:
            www.cr-3d.de

            Facebook:
            https://www.facebook.com/cr3d.official

            Our Discord Server
            https://discord.gg/SxRaPNuRdA

            Thingiverse Profile:
            https://www.thingiverse.com/cr-3d_official/about

            CR3Dundefined T3P3Tonyundefined 2 Replies Last reply Reply Quote 0
            • CR3Dundefined
              CR3D @CR3D
              last edited by

              @dc42 any idea or better a solution for this? ๐Ÿ™‚

              Christian from CR-3D
              Homepage:
              www.cr-3d.de

              Facebook:
              https://www.facebook.com/cr3d.official

              Our Discord Server
              https://discord.gg/SxRaPNuRdA

              Thingiverse Profile:
              https://www.thingiverse.com/cr-3d_official/about

              1 Reply Last reply Reply Quote 0
              • T3P3Tonyundefined
                T3P3Tony administrators @CR3D
                last edited by

                @cr3d said in RRF 3.4 Beta 7 | Tool-Offsets Issue:

                G1 R2 X0 Y0 Z2 ; restore position 2mm above

                By having this command you are moving the T1 to the position of T0 before the tool change was commanded. I think that's not what you want to do if you are first parking T0 using some gcode in the print file, and then commanding the tool change.

                is that what is happening? It would be good to share part of a gcode file you are printing along with all the tool change macros so we can understand what behaviour is happening in more detail.

                www.duet3d.com

                CR3Dundefined 1 Reply Last reply Reply Quote 0
                • CR3Dundefined
                  CR3D @T3P3Tony
                  last edited by

                  @t3p3tony Thank you for your Answer!

                  The command was just integrated because it was prescribed in the change log that it should now be used like this.

                  Basically, we've used it before because it's good to move over the component first and then lower Z when changing tools.

                  As I said, it just doesn't work anymore since the update!

                  No Gcode is necessary at all, this also happens if you last had the tool far outside and after the tool change the print head wants to go back to the old position and then crashes.

                  Christian from CR-3D
                  Homepage:
                  www.cr-3d.de

                  Facebook:
                  https://www.facebook.com/cr3d.official

                  Our Discord Server
                  https://discord.gg/SxRaPNuRdA

                  Thingiverse Profile:
                  https://www.thingiverse.com/cr-3d_official/about

                  T3P3Tonyundefined dc42undefined 2 Replies Last reply Reply Quote 0
                  • T3P3Tonyundefined
                    T3P3Tony administrators @CR3D
                    last edited by T3P3Tony

                    @cr3d said in RRF 3.4 Beta 7 | Tool-Offsets Issue:

                    after the tool change the print head wants to go back to the old position

                    yes, this is the purpose of the G1 R2 command so in that sense its working as intended - returning the tool head to the position of the previous tool. If you remove the G1 R2 commands from the print Tool change file, what happens?

                    www.duet3d.com

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

                      @cr3d I am reviewing your thread. You have reported two different issues:

                      1. The tool not being at the correct height after a tool change, when the tools have different Z offsets; and later:

                      2. Tools crashing into each other during a tool change.

                      In order that I can make progress, please provide:

                      1. Your complete config,g file
                      2. Your complete tool change files, and any macro files that they invoke;
                      3. The GCode file you are trying to print (at least up to and including the first few tool changes);
                      4. A description of what the issue(s) that you have at present, using firmware 3.4.2rc3.

                      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

                      CR3Dundefined 1 Reply Last reply Reply Quote 0
                      • CR3Dundefined
                        CR3D @dc42
                        last edited by

                        @dc42

                        I will make a new documaetation with the newest Firmware tomorrow.

                        The issue with the incorrect height after the tool change was fixed from you!

                        The only problem is the handling of the tool position (old position of the previous tool) after the toolchange... this is not working.

                        Christian from CR-3D
                        Homepage:
                        www.cr-3d.de

                        Facebook:
                        https://www.facebook.com/cr3d.official

                        Our Discord Server
                        https://discord.gg/SxRaPNuRdA

                        Thingiverse Profile:
                        https://www.thingiverse.com/cr-3d_official/about

                        dc42undefined T3P3Tonyundefined 2 Replies Last reply Reply Quote 0
                        • dc42undefined
                          dc42 administrators @CR3D
                          last edited by

                          @cr3d if it's just the height that needs to be corrected after a tool change to allow for the new tool Z offset, then you could use just G1 R2 Z0 at the end of the tpost file so that X and Y are not moved. This should be sufficient if the slicer always generates a travel move after the T command and before the first extruding move.

                          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
                          • T3P3Tonyundefined
                            T3P3Tony administrators @CR3D
                            last edited by

                            @cr3d does the slicer always generate a travel move to the new tool start position after the tool change command? If so then please see if DC42s solution works.

                            www.duet3d.com

                            1 Reply Last reply Reply Quote 0
                            • VoodooBaneundefined
                              VoodooBane
                              last edited by

                              So I am having this issue of the u-axis not having the same Z-height on the X axis .. this is assumed by the T1(the second extruder) not laying down a layer...

                              My bed is pretty darn flat. I have both of my Z-axis rods independent and I have them auto tram...

                              I figured out that for Slic3r (any kind of Slic3r fork) with RepRap firmware the retractions, Z-lift values, and speeds NEED to be in the setup in RRF firmware, and all of the settings need to be disabled in Slic3r. I do not know how I found this out.

                              Source: https://blog.prusa3d.com/slic3r-and-marlin-configuration-for-reprap-firmware-retraction-2_3686/

                              I am running a V-cast 1.5 please see the link: https://myhub.autodesk360.com/ue2a0f85b/g/shares/SH35dfcQT936092f0e43f11e68d181475a37
                              The only difference to that model is that I am running a different extruder and hot-end.

                              Can anyone help me with this problem and find a solution? It seems no one has found a fix or what they did to fix it.

                              All my .config files are attached; please tell me if you see something wrong.

                              bed.g
                              config.g
                              homeall.g
                              homeu.g
                              homex.g
                              homey.g
                              homez.g

                              1 Reply Last reply Reply Quote 0
                              • VoodooBaneundefined
                                VoodooBane
                                last edited by

                                Also here are my tool files;

                                tfree0.g
                                tfree1.g
                                tpost0.g
                                tpost1.g
                                tpre0.g
                                tpre1.g

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

                                  @VoodooBane you're best off starting a new thread rather than hijacking someone elses

                                  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

                                  VoodooBaneundefined 1 Reply Last reply Reply Quote 0
                                  • VoodooBaneundefined
                                    VoodooBane @jay_s_uk
                                    last edited by VoodooBane

                                    @jay_s_uk Ah yes will do. My mistake. Did mean to hijack anything..lol I will start a new thread. Sorry about that.

                                    sebkritikelundefined 1 Reply Last reply Reply Quote 1
                                    • sebkritikelundefined
                                      sebkritikel @VoodooBane
                                      last edited by

                                      @VoodooBane said in RRF 3.4 Beta 7 | Tool-Offsets Issue:

                                      @jay_s_uk Ah yes will do. My mistake. Did mean to hijack anything..lol I will start a new thread. Sorry about that.

                                      If you get a chance to make a new thread, please upload a sample gcode file. I haven't been able to reproduce the issues described by @CR3D on my IDEX machine.

                                      Large(ish?) IDEX - 6HC, 1HCL
                                      Stratasys Dimension 1200es to 6HC Conversion

                                      VoodooBaneundefined 1 Reply Last reply Reply Quote 1
                                      • VoodooBaneundefined
                                        VoodooBane @sebkritikel
                                        last edited by

                                        @sebkritikel I actually figured it out... lol I was doing a negative value on my T1 z-offset. But I changed, I got rid of the negative sign on the Z offset. it is working now. the layers are going down now.

                                        Only wish I could use a fork of slic3r that allowed you to adjust the z-hop, z-retration, etc in the slicer itself instead of the firmware.

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