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

    error start printing

    Scheduled Pinned Locked Moved
    Firmware installation
    4
    13
    463
    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.
    • Nxt-1undefined
      Nxt-1
      last edited by

      @dutti My expecience with tool changers is very limited but I believe there should be tool change macro's on your system that handle the actual C axis movements. Could you post these too please, my guess is that something in there could be causing your axis to become unhomed.

      Duet3D and delta printer enthousiast. Buildlog
      Looking for Duet3D configuration support, check out Nxt-3D

      duttiundefined 1 Reply Last reply Reply Quote 0
      • duttiundefined
        dutti @Nxt-1
        last edited by

        @nxt-1 50b8c574-2fb8-4049-8da8-bef2387d1ea8-image.png

        b5e64e77-0abe-41e6-a791-eaca08577284-image.png

        1 Reply Last reply Reply Quote 0
        • jens55undefined
          jens55
          last edited by

          If you are using a tool changer such as the Jubilee, there is a problem with using Cura. Cura will insert a few commands prior to running the start script. In particular, it will insert a T0 command that plays havoc with the Jubilee since it can't home with a tool installed.
          What actually happens is that Cura calls for T0 and then you try to home in your start script and that is where the printer gets screwed up.
          One of the ways to work around the issue is to edit the Cura generated gcode file to remove the initial tool selection. Another workaround is to insert a T-1 as your first line in your start script. The third work around is to remove any homing from your start script and make sure that you manually home the printer before you run the Cura generated gcode.
          While I haven't tested all the workarounds listed, I am sure at least one will get you going.

          Phaedruxundefined 1 Reply Last reply Reply Quote 1
          • Phaedruxundefined
            Phaedrux Moderator @jens55
            last edited by Phaedrux

            @jens55 said in error start printing:

            The third work around is to remove any homing from your start script and make sure that you manually home the printer before you run the Cura generated gcode.

            The easiest way to do this would be to use a start.g macro in the system folder. It gets called at the start of a job and gets executed before the sliced gcode file. So you can do all of your print prep there before the cura code takes over.

            Z-Bot CoreXY Build | Thingiverse Profile

            jens55undefined 1 Reply Last reply Reply Quote 0
            • jens55undefined
              jens55 @Phaedrux
              last edited by

              @phaedrux, it took me a bit before I fully understood what you were saying but I think this is an excellent idea. Basically you pull a 'Cura' on Cura by executing code before Cura can execute the code the precedes the start script of Cura ... LOL
              While I haven't tried it out, I think this is in fact the most elegant solution to this mess. Execute the homing before Cura can call for the first extruder!
              Thank you!

              1 Reply Last reply Reply Quote 0
              • Phaedruxundefined
                Phaedrux Moderator
                last edited by

                The majority of my "start" gcode lives in start.g right now. It also has the benefit of being slicer agnostic. All the slicer is in charge of now is final temp setting and calling a purge line macro.

                Z-Bot CoreXY Build | Thingiverse Profile

                jens55undefined 1 Reply Last reply Reply Quote 0
                • jens55undefined
                  jens55 @Phaedrux
                  last edited by

                  @phaedrux said in error start printing:

                  The majority of my "start" gcode lives in start.g right now. It also has the benefit of being slicer agnostic. All the slicer is in charge of now is final temp setting and calling a purge line macro.

                  Is 'stop.g' the last executed file after a print is finished? Do you use it instead of the ending script in the slicer ?

                  BTW, your solution with using 'start.g' works a treat !

                  Phaedruxundefined 1 Reply Last reply Reply Quote 0
                  • Phaedruxundefined
                    Phaedrux Moderator @jens55
                    last edited by

                    @jens55 said in error start printing:

                    Is 'stop.g' the last executed file after a print is finished? Do you use it instead of the ending script in the slicer ?

                    Stop.g gets called by M0. So I have M0 as the end gcode in my slicers.

                    Z-Bot CoreXY Build | Thingiverse Profile

                    jens55undefined duttiundefined 2 Replies Last reply Reply Quote 0
                    • jens55undefined
                      jens55 @Phaedrux
                      last edited by

                      @phaedrux , thanks !

                      1 Reply Last reply Reply Quote 0
                      • duttiundefined
                        dutti @Phaedrux
                        last edited by

                        @phaedrux
                        sorry I was in vacation..

                        and yes that works really good. thanks for this idea!

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