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

    start.g -> end.g?

    Scheduled Pinned Locked Moved
    Firmware wishlist
    5
    15
    1.1k
    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.
    • A Former User?
      A Former User @alankilian
      last edited by A Former User

      @alankilian
      Thanks so much for the fast reply!

      So it seems there is a standardization for a start.g
      https://duet3d.dozuki.com/Wiki/Macros#Section_Start_pause_stop_and_power_fail
      within the "system" folderstructure
      but sadly not yet an end.g

      (I would like to have certain things done before and after a print without having the need to have in the slicer the call for a macro -> the reason is it would be more error proof to have certain things not in the hands of diffrent users slicing ther different models and maybe include/forget to call some start and end stuff but rather have it always on the printer no matter what file is printed)

      Guess I call for a feature-request then to think about adding this to 3.2-alpha or 3.3 or so?

      1 Reply Last reply Reply Quote 0
      • alankilianundefined
        alankilian
        last edited by alankilian

        "stop.g is optional, but if present is run when a print finishes normally with an M0 command at the end of the print job."

        Will this do what you want automatically when a print finishes?
        I don't quite understand the " with an M0 command at the end of the print job." so I don't know if you would need to make sure that got added in the slicer or not.

        It might be fun just to try and see what happens. (My printer is unavailable or I'd test it myself.)

        SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300

        A Former User? Phaedruxundefined 2 Replies Last reply Reply Quote 0
        • A Former User?
          A Former User @alankilian
          last edited by A Former User

          @alankilian

          Thanks I read about this with some posts from phaedrux but there is a chance here at work that some people might forget to put that ("M0") into their slicer? The best would be to have the freedom to have all that end-stuff on the printer in an optional end.g so it does not matter who prints what. This is especially useful if you want to print the same file on different hardware that need different endings. What do you think?

          alankilianundefined 1 Reply Last reply Reply Quote 0
          • alankilianundefined
            alankilian @A Former User
            last edited by

            @LB I think that would work best for you since you don't feel everyone will add the M0 in their slicer configuration.

            SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300

            A Former User? 2 Replies Last reply Reply Quote 0
            • A Former User?
              A Former User @alankilian
              last edited by A Former User

              This post is deleted!
              1 Reply Last reply Reply Quote 0
              • A Former User?
                A Former User @alankilian
                last edited by A Former User

                @alankilian

                Where this idea comes from: We have at work here 3 different types of printers that will all get a new "brain"-board the duet3mini, but they are different in their size, buildup, hotend maybe (to be discussed) and I fear that everything that is machinerelated should be out of the way when we save the actual "print-files" on the company server (and of course always the raw-cad-file + the .stl-file) that way a once generated print file for let´s say:

                • RRF-flavour
                • ABSolut-xyz
                • RELative-E-steps
                • YOUR-DESIRED-material

                or so will print even after years pretty fine, because basically there is only the actual print in the file with the filamenttemperature or the filament call and that´s it. Basically nothing about the hardware and homing and so on.

                What do you think about that? Thanks so much for your input!

                I think I wait a day or more to see what people might post here?

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

                  @alankilian said in start.g -> end.g?:

                  so I don't know if you would need to make sure that got added in the slicer or not.

                  Yes you would need M0 at the end of the print file to execute stop.g

                  I'll move this to the wishlist since having an end.g that behaved similar to start.g without requiring a call would be a useful addition.

                  Z-Bot CoreXY Build | Thingiverse Profile

                  A Former User? 1 Reply Last reply Reply Quote 4
                  • A Former User?
                    A Former User
                    last edited by

                    This post is deleted!
                    1 Reply Last reply Reply Quote 0
                    • A Former User?
                      A Former User @Phaedrux
                      last edited by

                      More people giving this a vote up?

                      fcwiltundefined 1 Reply Last reply Reply Quote 3
                      • fcwiltundefined
                        fcwilt @A Former User
                        last edited by

                        @LB said in start.g -> end.g?:

                        More people giving this a vote up?

                        I think it is a grand idea and my gut says it would not be hard to do.

                        As you have observed we have start.g but I don't happen to use it because it occurs before any slicer generated code.

                        I endeavor to find how to have the slicer call my own "start" file just before it starts the actual printing so any code I include does not get overridden by slicer code.

                        For the firmware to do this it would have to analyze the slice code stream and determine when actual printing starts and I don't see that as happening.

                        The file end.g would work just fine since it occurs at what I see as the appropriate time.

                        Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6

                        A Former User? 1 Reply Last reply Reply Quote 0
                        • A Former User?
                          A Former User @fcwilt
                          last edited by A Former User

                          @fcwilt
                          Thanks!

                          (Any more voting this (optional system file) up, maybe for 3.3 or 3.4?)
                          Lucas

                          1 Reply Last reply Reply Quote 1
                          • oliofundefined
                            oliof
                            last edited by

                            I would like to see an end.g because I use many slicers for specific printers or use cases, and tweaking endcode in the slicer is not always appropriate for me.

                            <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

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

                              @oliof M0 at the end of the print file to execute stop.g is not sufficient?

                              Z-Bot CoreXY Build | Thingiverse Profile

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