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

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

[A Former User]

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.

[dc42]

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

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

Please test that again. That's not what should happen, and I can't think of any type of firmware bug that would cause that. If there is no stop.g or cancel.g file, then the heaters should be turned off by the firmware. Except if you terminate it using DWC and it sends the H1 parameter on the M0 command. [I didn't agree with the introduction of the H1 parameter, and I am minded to remove it.]

[alexjx]

I observed a similar issue recently too. When sending "M0 H1", if I put any code into stop.g, my heaters are all off and my tool got deselected. But the behavior is different if the file is empty. I believe this is a bug. I think the problem happens because the machine state is pushed to stack but the gcode buffer is not.
The stopping logic is executed after the macro runs, then testing the "H" flag. By then the gcode buffer contains the last line in the macro. The stopping will always be executed as if there is no "H" flag. This is confirmed if I put an "M117 H1" into the last line of stop.g, "M0 H1" behaves as expected.

I currently don't have a simple solution, since the state should be set to "normal" when macro exists, but by then the state has already pushed to stack...

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

[I didn't agree with the introduction of the H1 parameter, and I am minded to remove it.]

I think the H flag has its use for cases. Excuse me that I'm new to RRF. But I found that once the heater got disabled, only tool re-select will enable it back on.
I have a dual extrusion printer, similar to an Ultimaker 3 with a lifted second nozzle. With this setup, the "no tool selected" state is actually invalid.
If the current mechanically activated tool is selected again, the switch will hit the switching dock in a very unpleasant way. If there is no other solution, I think the "H" flag, in this case, will benefit my scenario.

[dc42]

Thanks @gnydick and @alexjx, I confirm this is a bug. I will fix it in firmware 2.03RC4.

[dc42]

This is now fixed.

[alexjx]

@dc42 Confirmed working. Thanks.