start.g -> end.g?

alankilian

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

A Former User

This post is deleted!

A Former User

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?

Phaedrux

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

A Former User

This post is deleted!

A Former User

More people giving this a vote up?

fcwilt

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

A Former User

@fcwilt
Thanks!

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

oliof

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.

Phaedrux

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