start.g -> end.g?
-
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?
-
@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
-
This post is deleted! -
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?
-
@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.
-
@fcwilt
Thanks!(Any more voting this (optional system file) up, maybe for 3.3 or 3.4?)
Lucas -
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.
-
@oliof M0 at the end of the print file to execute stop.g is not sufficient?
