Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    Toolhead preheat prior to a tool change.

    Firmware wishlist
    7
    13
    670
    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.
    • thomaspj
      thomaspj last edited by

      I was hoping for some sort of look ahead function during printing that will set the standby temperature to active on an inactive toolhead 'x' number of gcode lines ahead of the tool change 'T#' so as to cut down on print times waiting on the hotend to re heat during tool changes.

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

        We plan to implement this on Duet 3, by having 2 readers reading the same GCode file. Reader #1 will do the printing, while reader #2 will run in simulation mode and stay ahead, so that it can tell #1 in advance that a tool heater should be switched to active temperature, or (for a mixing extruder) that the mix should be changed.

        On Duet 2 there probably isn't enough RAM to do this easily, because of the additional DDAs needed to run a simulation in parallel with a real print.

        Cura has a facility to advance tool heating and I believe some users have it working with Duets

        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

        TechNi 1 Reply Last reply Reply Quote 1
        • fma
          fma last edited by

          Why not just implement a pre-processor, more or less like the simulator, to add the heating G-Code lines? This is something one can do using a Python or Perl script, before sending the G-Code to the Duet, but it should not be difficult to implement it on the Duet itself, and should not need much RAM...

          Frédéric

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

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

            Why not just implement a pre-processor, more or less like the simulator, to add the heating G-Code lines? This is something one can do using a Python or Perl script, before sending the G-Code to the Duet, but it should not be difficult to implement it on the Duet itself, and should not need much RAM...

            To handle forseeable cases such as needing to advance tool heating by 20 seconds when drawing curved perimeters that take 0.1 seconds per segment of the curve, you would need to buffer up to about 200 moves. That would need too much RAM to do it on the Duet.

            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
            • fma
              fma last edited by

              Sorry, I was not clear: I was thinking the pre-processor to really pre-process the file, and add some lines to it (on the SD card) without printing. Then, just run the new file as usual...

              Frédéric

              deckingman 1 Reply Last reply Reply Quote 0
              • dragonn
                dragonn last edited by

                Maybe it would be possible to write a simulator for DuetWebControl so it runs in a browser. This way you could prepare the g-code at upload time by using the computer resources

                1 Reply Last reply Reply Quote 0
                • deckingman
                  deckingman @fma last edited by

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

                  Sorry, I was not clear: I was thinking the pre-processor to really pre-process the file, and add some lines to it (on the SD card) without printing. Then, just run the new file as usual...

                  That would do - I guess you are thinking of much the same way as I advance the tool change point in the gcode file for colour changes. As you say, a Python script or some such.

                  Ian
                  https://somei3deas.wordpress.com/
                  https://www.youtube.com/c/deckingman/

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

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

                    We plan to implement this on Duet 3, by having 2 readers reading the same GCode file. Reader #1 will do the printing, while reader #2 will run in simulation mode and stay ahead, so that it can tell #1 in advance that a tool heater should be switched to active temperature, or (for a mixing extruder) that the mix should be changed.
                    On Duet 2 there probably isn't enough RAM to do this easily, because of the additional DDAs needed to run a simulation in parallel with a real print.
                    Cura has a facility to advance tool heating and I believe some users have it working with Duets

                    @dc42 Sorry for necroing this thread but was this ever implemented? This would actually be useful since some slicers (like PrusaSlicer) don't pre-heat tools before a toolchange happens.

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

                      @techni it's still on the firmware wish list.

                      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

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

                        @dc42 I'm glad this old thread popped up. Now I know what you're planning with the multi gcode stream.
                        My hashPrinter will take a while before it could benefit from "printing with two heads" simultaneously.
                        But I'd like to know, if that's also possible then?

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

                          @o_lampe yes the intention is to allow printing multiple streams in parallel, with the GCode commands for both streams in the same file, more or less interleaved, and a facility to synchronise the two streams at various points in the file.

                          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

                          deckingman o_lampe 2 Replies Last reply Reply Quote 0
                          • deckingman
                            deckingman @dc42 last edited by deckingman

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

                            @o_lampe yes the intention is to allow printing multiple streams in parallel, with the GCode commands for both streams in the same file, more or less interleaved, and a facility to synchronise the two streams at various points in the file.

                            David,
                            Would this be a mechanism for advancing the tool change point within a file? I don't know if you recall but we've talked about this in the past. It's a useful way to reduce or even eliminate the need for purging when changing between colours with a mixing hot end. I currently use a post process python script to achieve this but that's a bit of a pain. The ability to "tune" the tool change positional offset "on the fly" would be awesome.

                            EDIT. The ability to have "Tn" acted on within a move would be even more awesome. Currently, my post processing scrip has to segment existing G1 moves in order to get the Tn where it needs to go.

                            Ian
                            https://somei3deas.wordpress.com/
                            https://www.youtube.com/c/deckingman/

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

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

                              @o_lampe yes the intention is to allow printing multiple streams in parallel, with the GCode commands for both streams in the same file, more or less interleaved, and a facility to synchronise the two streams at various points in the file.

                              That's really great news and motivates me even more to get it finished.
                              Can I assume there is a solution for multiple (mini) Z-axis in the pipeline, too? Printing with mesh leveling and two or more tools involved wouldn't work convenient without it.

                              My proposal was to use mini Z-axis on each toolholder and apply mesh leveling and Z-hop to them when no Z-value is in the gcode line.
                              When there's a Z-value in the gcode, it's a layer change and will move the main Z-steppers.
                              My favourite mini z-axis would be a small geared DC motor with leadscrew and quadrature encoder, but I could live with a light stepper motor and excenter, too.
                              Maybe it needs a new toolboard, which can drive two motors? (direct drive extruder and mini-Z)

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