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

    Toolhead preheat prior to a tool change.

    Scheduled Pinned Locked Moved
    Firmware wishlist
    11
    28
    2.8k
    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.
    • hestiahuangundefined
      hestiahuang @jay_s_uk
      last edited by

      @jay_s_uk said in Toolhead preheat prior to a tool change.:

      @hestiahuang it's part of the 3.5b1 release a few weeks back

      Sorry, need to distube you again. I read the change log carefully, however I can't see any description about this part. Any idea about the details of this change?

      https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta2-in-preparation
      https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta1

      o_lampeundefined jay_s_ukundefined 2 Replies Last reply Reply Quote 0
      • Rushmere3Dundefined
        Rushmere3D
        last edited by

        There is a 3rd party PrusaSlicer post processor for this if your interested?

        Follow my adventures in 3D Printing, laser cutting and electronics. https://linktr.ee/Rushmere3D

        1 Reply Last reply Reply Quote 0
        • o_lampeundefined
          o_lampe @hestiahuang
          last edited by

          @hestiahuang I proposed to establish a tahead.g macro which runs, as soon as the look ahead planner finds a toolchange.
          This could probably be too late, depending on the length of look ahead.
          Finding the best solution is way harder, since each line of code can take longer or shorter.
          My dual extruders always run at full temperature. Even when a tool is parked. I park the nozzle over a piece of nylon to prevent oozing and purge the tool, when it's reactivated.

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

            @hestiahuang its part of the multiple motion support. https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta1:~:text=[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] Multiple motion systems are supported. See https%3A//docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems. Caution%3A this feature is experimental and may not be fully working in this release.
            there are now 2 gcode streams. however, how a user chooses which gcode stream is used I am unsure of

            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

            o_lampeundefined hestiahuangundefined 3 Replies Last reply Reply Quote 0
            • o_lampeundefined
              o_lampe @jay_s_uk
              last edited by

              @jay_s_uk I guess these links won't work 🙂

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

                @o_lampe works fine here (using googles copy link to highlight function)

                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

                o_lampeundefined 1 Reply Last reply Reply Quote 0
                • o_lampeundefined
                  o_lampe @jay_s_uk
                  last edited by

                  @jay_s_uk You've posted one link, but it contains two http....addresses?

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

                    @o_lampe click it and see.....

                    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
                    • o_lampeundefined
                      o_lampe @jay_s_uk
                      last edited by

                      @jay_s_uk said in Toolhead preheat prior to a tool change.:

                      there are now 2 gcode streams. however, how a user chooses which gcode stream is used I am unsure of

                      What I'm gathering from it is:

                      • you slice two different parts (located at different places on the bed)
                      • each part has it's own gcode file
                      • In their start code you specify the tool number with M596 (both files will have X,Y and E components, but we don't need postprocessing to rename XY axes)

                      What I don't get is, how it will handle layer changes
                      And it doesn't preheat a tool, since both tools are working

                      1 Reply Last reply Reply Quote 0
                      • hestiahuangundefined
                        hestiahuang @jay_s_uk
                        last edited by

                        @jay_s_uk said in Toolhead preheat prior to a tool change.:

                        @hestiahuang its part of the multiple motion support. https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta1:~:text=[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] Multiple motion systems are supported. See https%3A//docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems. Caution%3A this feature is experimental and may not be fully working in this release.
                        there are now 2 gcode streams. however, how a user chooses which gcode stream is used I am unsure of

                        Great to hear that, even it is for Duet3 6HC. Thanks a lot!

                        1 Reply Last reply Reply Quote 0
                        • hestiahuangundefined
                          hestiahuang @o_lampe
                          last edited by

                          @o_lampe said in Toolhead preheat prior to a tool change.:

                          @hestiahuang I proposed to establish a tahead.g macro which runs, as soon as the look ahead planner finds a toolchange.
                          This could probably be too late, depending on the length of look ahead.
                          Finding the best solution is way harder, since each line of code can take longer or shorter.
                          My dual extruders always run at full temperature. Even when a tool is parked. I park the nozzle over a piece of nylon to prevent oozing and purge the tool, when it's reactivated.

                          Any link about your tahead.g? Oh... I think I can check your post history and locate it. Thanks!

                          1 Reply Last reply Reply Quote 0
                          • dwuk3dundefined
                            dwuk3d
                            last edited by

                            Just came across this old thread, and some of the thoughts in it are relevant to some work I am currently doing.

                            A few years ago when I was using a Marlin based IDEX machine with a fairly slow heating element I did write a gcode post processor that parsed the gcode and inserted pre-heat commands into the gcode stream approximately the right number of instructions ahead to take into account the likely execution time of the individual gcode instructions, plus the amount of heating time required based on approximate heat up rate, plus previous cool down rate.

                            I don't think the multiple motion systems enhancements really help with this so I am embarking on looking at preheating again based on a multiple motion systems/multiple idex/tool changer system I am working on:

                            Things that need to be considered are:

                            1. The faster heat up times of more modern extruders meaning timings need to be fairly accurate - or maybe they are fast enough to largely negate the benefits of preheating.
                            2. Gcode queuing/multiple queues means that working out where in the gcode stream to place the preheat instructions is fairly complicated.
                            3. Working out how long each move/extrude is actually going to take it quite tricky too given acceleration/slow downs both prior and after each instruction.

                            I guess ideally the slicer and firmware would handle this, but in the meantime
                            I'm thinking maybe some global variables indicating future preheat timings, and use of daemon.g might end up being part of the solution.

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