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

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.

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.