M0 not behaving as I would expect it to..

Phaedrux

@JADoglio said in M0 not behaving as I would expect it to..:

When I add M25 as the first line of stop.g to pause the print, I get the same error and the print does not stop.

I don't think that's going to work. You'd have to issue the pause first, and then cancel.

What exactly are you trying to achieve?

dc42

@JADoglio M0 was originally intended to be used in sequential job files. In RRF it is also allowed to terminate a paused job, to save inventing another command. It is not intended to instantly stop a running Job. You should use M112 for that.

JADoglio

@dc42

Phaedrux, I was just trying to find a way to do one click stop print with the option to leave the heaters on. I often find I start a print and quickly figure out that I made some mistake and need to adjust something. It is easy enough to do it with pause and cancel. The issue is it takes a few more seconds while the system writes the resume data and then calls the option to cancel and it also turns off the heaters and fans even though the next print starts seconds later. I thought this would be easy.

It seems it is not. In trying to do this I also became very familiar with the process and limitations of M0. I was also a bit surprised to learn that M0 is called automatically at the end of every print. I use a stop print macro to do the same things, not knowing it was not needed. I understand this was probably built in for safety reasons. The feature to make sure the heaters and fans were turned off after the print is good but it would be nice to have the option to manually turn that off and use my own macros to manage how the print ends..

DC42, thanks for the suggestion. Based on the above you have probably figured out why M112 is not a preferred option.

I appreciate the help. You might want to consider update M0 so when it is issued from the command line it pauses the print (if it is not already), then stops the print using stop.g.

dc42

@JADoglio you can create a macro to pause and cancel a job with one press of a button.

JADoglio

@dc42

Interesting, I have written a lot of macros and I have been learning how to use variables and and adding logic to the macros. So, of you are referring to just creating a macro to this, that is not what I am looking for. If I can create a macro and then create a button on the status page (on both the DWC and the Panel Due) to activate it, that would be perfect? Is that possible? If it is, what resources can you point me to to see how this would work. Thanks

dc42

@JADoglio you can have macro buttons on the Dashboard page of DWC (Control page of PanelDue) but not on the Status pages.

There is a plugin for DWC called BtnCmd (https://github.com/MintyTrebor/BtnCmd) that lets you create custom layouts and buttons - perhaps that would be useful to you.

JADoglio

@dc42 Thanks I will have a look!

JADoglio

Thanks, I installed the add in and it should be useful. Can buttons be added to the standard pages that already exist in DWC like "Status" or "Dashboard" using this tool, or is that beyond what it was designed to do? Also, this only solves part of the issue. The bigger issue is how do I cancel or intercept the inherent M0 issued by Rep Rap so the firmware does not ALWAYS turn off the heaters at the end of the gcode execution for a print. Since the inherent M0 runs after the machine configured end print script runs, I should be able to intercept it and cancel/modify it before it executes. I am pretty sure at this point that it can't be, but it seems I should be able to configure the execution of my files to behave as I want them to. Your thoughts are always appreciated.

jay_s_uk

@JADoglio no, it can't add buttons to other pages than it's own.
I use global variables if I want to override heaters turning off https://github.com/TeamGloomy/Troodon-V2/blob/improved/Config/sys/stop.g

dc42

@JADoglio said in M0 not behaving as I would expect it to..:

The bigger issue is how do I cancel or intercept the inherent M0 issued by Rep Rap so the firmware does not ALWAYS turn off the heaters at the end of the gcode execution for a print.

When M0 is executed within a print job (and in 3.6, when the end of the job file is reached without encountering M0), RRF runs file sys/stop.g if it exists, otherwise it uses the default behaviour which is to turn off all heaters. So you can change the behaviour by creating a stop.g file.

When M0 is run when the print is paused. RRF first tries to run sys/cancel.g, then if that isn't found it behaves as above.