end.g

milangupta1

Please include support for triggering end.g (if it exists) at the end of a job.
Rational :

start.g is supported currently
allows for cleaner separation of firmware and slicer generated gcode

I am trying to use my slicer (Simplify3d) to generate g-code files and then print them on my duet3d enabled printer (rebuilt Makerbot 2x). I have configured duet3d to be more or less independently operatable (startup/initialization/calibration/homing etc.) from the paneldue or webcontrol. There are still a few kinks although where behavior is dependent on gcode file.

Eg. in the simplest of tasks to play a tune at the end of a job, it requires a M0 command at the end of gcode in order to trigger stop.g currently. In simplify3d, the generated g-code does not include this at the end unless explicitly configured as an "ending script" in simplify3d. I see this as something that should be configured in the machine / firmware vs. the slicing software.

Thanks for considering ..

Dougal1957

This post is deleted!

T3P3Tony

@milangupta1 to confirm - you want the printer to automatically run "end.g" at the completion of every SD card job, as a default? This has already been discussed and the macro simplay has a different name: stop.g, as you have found

See this thread for example:
https://forum.duet3d.com/topic/9410/end-g-is-possible/12

I don't understand why it is difficult to use stop.g? Is this because simplify3d does not allow configuration of the file name? If that tis the case and simplify 3d is putting a call to end.g into the end of the gcode then creating an end.g file should make that work.

@milangupta1 said in end.g:

I see this as something that should be configured in the machine / firmware vs. the slicing software.

So the issue is simply that you have to add M0 to the end of the gcode?

I think it is preferable to have this requirement (which can be automated in all slicers) rather than forcing every user to have an automatic function. some users do not want anything to happen at the end of the file (maybe because they will immediately print another one? e.g. on a beltprinter

A Former User

I tend to agree, its inconsistent to have explicit start.g but implicit stop.g. Adding end.g would allow both to be optional, but more complex.

milangupta1

@t3p3tony Of course, I have already hacked it to make it work by adding "M0" to the simplify3D config.

The designer in me, however, is looking for something cleaner and elegant. I am assuming that a clean separation/layering of hardware/firmware/software is still a design principle ? I think it will allow folks who build machines using the duet3D board more flexibility to sell machines vs. machines + tightly coupled slicing software.

Am not picky or debating language symmetry i.e. stop vs end.
start -> stop/end (Although, I instinctively think of stop as "emergency stop").
pause -> cancel/resume

These are all built in with the exception of end. What I cannot figure is why "stop" has the requirement of having M0 in the gcode file when the firmware already knows the file has completed processing.

My recommendation is to just decouple "stop" from M0 or make it config option as a required dependency for trigger. Remember, this recommendation came from inconsistent behavior of slicer programs on what gcode they generate. Simpler would be to just leave "stop" behavior to what it is and introduce "end.g" and trigger it if it exists (in addition).

T3P3Tony

@milangupta1 ah ok, fair enough so either;
a) Have stop.g run without M0.
or
b) Have end.g run without M0.

Of these i agree having end.g may be preferable because it wont force behaviour on existing users that want to explicitly call M0 - but it would be good to not have an error if end.g is not found.

lets see what David and others think.

milangupta1

@t3p3tony You got it ! Option b would be my choice and I would definately not make it an error if "end.g" isn't found. That will keep backward compatibility as well as make it optional for anyone to use the end.g macro .. just a feature !