start.g -> end.g?

  • Hi,

    I just stumbled across the info, that I could create within the sys folder or macros folder a file named start.g that would be executed before all else if a print gets started.
    Does the same hold true if I create a file called end.g that is the absolut last thing executed in the end of a print?

  • Here's a page that describes start.g and other files and says when they are run.

  • @alankilian
    Thanks so much for the fast reply!

    So it seems there is a standardization for a start.g
    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?

  • "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.)

  • @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 into their slicer? The best would be to have it on the printer in a end.g so it does not matter who prints what. What do you think?

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

  • This post is deleted!

  • @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?

  • Moderator

    @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.

  • This post is deleted!

  • More people giving this a vote up?

  • @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.

Log in to reply