M1, M0, and DWC "Enable Auto-Sleep"

garyd9

Is the DWC "Enable Auto-Sleep" a browser function only? In other words, if I check that checkbox and close my browser before the print is finished, will the printer still run M1 at completion or not?

Second, if the gcode file being printed contains "M0" as it's last gcode command, will "M1" still be executed after the print is completed? (So, it'd end up running M0 (stop.g) followed by M1 (sleep.g)?)

Part of my motive for asking all this is that I finally got around to attaching a SSR to enable "M80/M81" functionality, and I think I'd like to do something to cause the printer to automatically turn off the 24V PSU once everything has cooled down (via M81 S1.) I'm just not sure if it'd be better to put that in sleep.g (and change my slicer's ending script to use M1 instead of M0) or stop.g.

dc42

The behaviour of M0 and M1 in RRF is somewhat inconsistent with the NIST standard. RRF doesn't really support a sleep mode at present.

Both M0 and M1 will terminate printing of the current file. So M0 followed by M1 wouldn't work because the M1 command won't be executed. If you always want to turn power of when a print job finishes, I suggest you put M81 S1 at the end of stop.g.

garyd9

@dc42:

The behaviour of M0 and M1 in RRF is somewhat inconsistent with the NIST standard. RRF doesn't really support a sleep mode at present.

Both M0 and M1 will terminate printing of the current file. So M0 followed by M1 wouldn't work because the M1 command won't be executed. If you always want to turn power of when a print job finishes, I suggest you put M81 S1 at the end of stop.g.

Wouldn't that also cause the printer to turn off after I cancel a print?

dc42

No, because when you cancel a print it runs cancel.g instead of stop.g.

garyd9

Oh, I was under the impression it ran M0 which caused stop.g to be run. This impression was from the comment that the configuration tool leave in the file:

; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)

Thank you for correcting my understanding.

Now I'll ask a slightly different question: If I send a "M81 S1" command in my stop.g, is there any way to cancel the impending PSU shutdown? (Or, more properly asked, is there any way to cancel the impending grounding of PS_ON?)

dc42

Looks like configtool needs to be updated to generate a more accurate comment. When M0 is received the firmware runs either stop.g or cancel.g depending on the context.

I think sending M80 may cancel a pending M81 but I can't remember for sure.

garyd9

After digging to validate, it does:

M81 S1 sets private variable Platform::deferredPowerDown to true… (and Platform::Spin() acts on it)
M80 calls platform.AtxPowerOn() which is defined as:

[[language]]
void Platform::AtxPowerOn()
{
	deferredPowerDown = false;
	IoPort::WriteDigital(ATX_POWER_PIN, true);
}

I should have checked the source before asking. (Of course, now that it's posted in the forum, the next person might find it with a search.)

Take care
Gary