end.g is possible?

[dc42]

Yes, if stop.g is present then M0 just waits for all moves to complete, sets the printer state to "idle", and runs the file. Even if stop.g isn't present, M0 doesn't turn the motors off.

[fma]

I have to admit that the use of M0, M1 is confusing, and does not allow enough freedom.

Why not only execute the corresponding macro, and provide a default one with what is described in the documentation? This way, we could tune it to match our exact needs...

[Anidal]

Fine! Probably, it is necessary to update the documentation so that there are no discrepancies.

[dc42]

I'll review the M0/M1 code before the next beta and update the documentation. The intended behaviour is:

• Wait for all moves to complete.
• Close the SD print file and change the printer status to Idle.
• If M0 was received while the printer was paused, execute cancel.g if it exists, else stop.g.
• If M0 was received while the printer was not paused, execute stop.g.
• If M1 was received, execute sleep.g.
• If the appropriate macro file is not found, take default action, which is to turn all heaters off. Motors are left on (but as always, if they are all idle for the idle timeout period then the motor currents will be reduced to the idle percentage).

[Phaedrux]

@dc42 said in end.g is possible?:

I'll review the M0/M1 code before the next beta and update the documentation. The intended behaviour is:

• Wait for all moves to complete.
• Close the SD print file and change the printer status to Idle.
• If M0 was received while the printer was paused, execute cancel.g if it exists, else stop.g.
• If M0 was received while the printer was not paused, execute stop.g.
• If M1 was received, execute sleep.g.
• If the appropriate macro file is not found, take default action, which is to turn all heaters off. Motors are left on (but as always, if they are all idle for the idle timeout period then the motor currents will be reduced to the idle percentage).

I would say this seems to be the case. I use M0 to call stop.g. I haven't tested the other behaviours in quite some time though.

[ctilley79]

I know this is probably a nitpicky issue, but it would be nice to have an automatic trigger so you don't have to call M0 in the slicer end code. I try to decouple as much from the slicer as possible, so there are a couple use cases where this could be polished. start.g and stop.g is one of them.

[fcwilt]

@ctilley79 said in end.g is possible?:

I know this is probably a nitpicky issue, but it would be nice to have an automatic trigger so you don't have to call M0 in the slicer end code. I try to decouple as much from the slicer as possible, so there are a couple use cases where this could be polished. start.g and stop.g is one of them.

You waited two years to respond?

You must have really given it a lot of thought first.

Frederick

[ctilley79]

This post is deleted!

[ctilley79]

@fcwilt said in end.g is possible?:

@ctilley79 said in end.g is possible?:

I know this is probably a nitpicky issue, but it would be nice to have an automatic trigger so you don't have to call M0 in the slicer end code. I try to decouple as much from the slicer as possible, so there are a couple use cases where this could be polished. start.g and stop.g is one of them.

You waited two years to respond?

You must have really given it a lot of thought first.

Frederick

I figured two years was enough time to let the thought simmer in DC42's mind lol

[A Former User]

Whoever reads this, you might vote this one up: https://forum.duet3d.com/topic/20708/start-g-end-g
Sorry have not seen this post when I put my request in the wishlist so I opened another post! Since my usecase is more detailed then here, I recommend to swap over to my request?

[Skimmy]

@dc42 If I execute stop.g via M0 at the end of my gcode-file, is it ok to have M0 inside of stop.g again to shut off the heaters?

[dc42]

@skimmy said in end.g is possible?:

@dc42 If I execute stop.g via M0 at the end of my gcode-file, is it ok to have M0 inside of stop.g again to shut off the heaters?

That's a good question! I haven't tested it.

[abear]

Hi @dc42 ,

I thought maybe, given how old this thread is, this had already been implemented, so I updated firmware. But alas no. I just tested and it does not. Hence my print ends with the hot end sitting against my print, still hot for 2 hours until I wake up.

Adding M0 manually to the end of the gcode via the slicer is a poor implementation.
M0 is a STOP or Unconditional STOP. Which that's exactly what it should do. STOP. Not, oh run this other gcode now.
In addition, I print from multiple printers and often use different slicers. Not only do I not want to apply this change to every slicer, I have different requirements for the end of a print for each machine. Therefore, it makes vastly more sense for the firmware to have a machine specific end.g to be appended to the end of each job. This way, I can customise the end print for each machine and don't have to have multiple machine profiles (so much) for each slicer.

I vote this UP. Please provide the facility to append the content of an end.g file to the end of every job.

Thanks
Adrian

[dc42]

@abear in the RRF3.5beta series stop.g is called when a print completes normally regardless of whether M0 is used.