Any g-code in stop.g causes heaters to turn off

gnydick

I've had no g-code in that file forever. I suddenly put in a command to stop the nozzle fans and now it's also turning off all of the heaters if I click cancel. Seems like a bug.

dc42

When you click Cancel, file cancel.g is run in preference to stop.g.

gnydick

@dc42 I don't have a cancel.g

dc42

Why not create one then, and in it put the commands you want to execute when you cancel a print? I have stop.g turn all heaters off; but I have cancel.g keep then on, because after using it I usually want to restart the same print.

gnydick

@dc42 yeah, that makes sense, but this feels like another example of assumed use case rather than the machine just doing what it's told. What If I didn't want the heaters to turn off at the end of the print?

jv43

@gnydick

What If I didn't want the heaters to turn off at the end of the print?

There is a checkbox under "Job Control" named "Enable Auto-Sleep".
When checked, all heaters are turned off once a job has finished.

Edit: sorry i misread your post.
maybe auto sleep is checked?

gnydick

@jv43 nope, auto sleep is not checked

jv43

@gnydick what firmware version are you running?
I never added a "cancel.g" and i just checked, it's in my sys files.
I just added

M106 P0 S0

to my cancel.g and it turned off the part cooling fan, while keeping all heaters on.

yeah, that makes sense, but this feels like another example of assumed use case rather than the machine just doing what it's told. What If I didn't want the heaters to turn off at the end of the print?

Using cancel.g when cancelling a print seems like the machine IS doing exactly what it's told.
So I don't really see the problem in creating cancel.g or updating your FW

gnydick

@jv43 no problem with using the cancel.g. my point was that intrinsic behavior is problematic. We have start, stop, layer change, tool change, etc. scripts in our slicers; I don't want my printer to get involved.

jv43

So you want to use M0 with your slicer?
try

M0 H1

and add

M106 P0 S0

to your stop.g
please test if thats now behaving as you want it to.

gnydick

@jv43 that's not my issue. I know how to program the machine. The fact that it does things with no instruction is what bothers me.

jv43

@gnydick running M0 with no H1 parameter shuts all heaters off. This is normal behaviour for any FW based on the RepRap FW and always worked that way afaik. I never used any other FW except for marlin, which is also based on RepRap, so i can't comment on the behaviour of other firmwares when executing M0.
This behaviour is documented on the RepRap wiki as well as the Duet documentation, so it does exactly what you instructed it to do?

fma

The difference is that RRF triggers macros (stop.g, cancel.g...).

Why not just call the macros, and do nothing if they are not there? By default, the macros could contained what is now implicitly done, so things are explicit, but can be more fine tuned...

The current behaviour, whith several if/then/else, is confusing.

gnydick

@fma that's exactly right. @jv43 my point has nothing to do with how to do it. It's the fact that the firmware does things WITHOUT being instructed to do so. That is, IMHO, never a good way to do things. In fact, the fact that we have access to all of these macros (/sys/*.g files) is the exact emblematic implementation of someone thinking a machine should only do what it's told and not have any innate logic. To expose the ability to customize everything and then have the machine do things that you can only change by editing the firmware itself, is counterproductive.

jv43

@gnydick I definately agree it would be better to put the gcode in the macro itself rather than having it be empty by default and have some other code run when no actual gcode is present in that macro, maybe @dc42 can give some insight why it was implemented this way (maybe for safety reasons if stop.g or cancel.g are not present/readable or corrupted in some way).
You're posting in tuning and tweaking, so I thought you mainly wanted to make it work.
In that case my suggestion would be to create cancel.g and add your code.

For fundamental changes to RRF I'd suggest you post in Firmware Wishlist.
David is currently working on RRF 3.0 and I think that thread is open for suggestions too.

fma

@jv43 said in Any g-code in stop.g causes heaters to turn off:

maybe for safety reasons if stop.g or cancel.g are not present/readable or corrupted in some way

If the SD card is corrupted, the M0/1/2 commands won't be executed anyway; the chance that the SD card fails right after the M0 command is read, and before the macro is read is close to nothing

We could also imagine a more global safety feature, shuting down the entire printer in case a SD corruption is detected.

jv43

@fma I wasn' talking about a corrupted sd card, but a corrupted file (maybe after unexected power loss during edit?)
M0 will work with no cancel.g/stop.g present and default behaviour is to shut off all heaters.

gnydick

@jv43 What's really strange logic is that cancel.g is preferred. I don't have a cancel.g. I had an empty stop.g. The heaters didn't turn off from a cancel.

Then when I added code to the stop.g, it did turn off the heaters. Either way, there was no cancel.g, so why did adding code to the stop.g cause the heaters to turn off when in both cases, there was no cancel.g. Just feels not so intuitive.

https://github.com/T3P3/Duet/blob/master/Duet2/SD Card Contents/sys/cancel.g

By default there is a cancel.g file.

wilriker

Also what is interesting here is the question how you cancel the print? DWC (both 1 and 2) will send M0 H1 which leaves the heaters on.