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



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


  • administrators

    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.



  • @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?


  • administrators

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



  • 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?)


  • administrators

    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.



  • 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


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.