RRF 3.2 Beta 1 SBC: cancel.g called instead of stop.g

[docbobo]

I am running RRF 3.2 beta 1 on a BTT SKR 1.4 Turbo with SBC
DSF Version 3.2.0-beta1+1
DWC Version 3.2.0-beta1+2

This problem also seems to be present in RRF 3.1.1 on SBC.

Here's the GCode I am testing with:

T0
M0

Based on documentation, I would've expected that stop.g is called afterwards, which seems to be happening in standalone mode (according to @jay_s_uk).

Instead, what's being called is cancel.g

[jay_s_uk]

Yep, I can confirm I have reproduced this bug.
With an SBC attached, M0 calls cancel.g (SKR + SBC) and in standalone mode (Mini 5+) M0 calls stop.g

[jay_s_uk]

another strange thing as well.
If M0 is called from within start.g (I know nobody would but using conditional gcode it could be called if certain checks aren't met) stop.g runs but then start.g carries on. I would've expected that macro loop to have been aborted.
This was in standalone mode

[T3P3Tony]

@jay_s_uk does your loop have an "break" in it after M0?

[jay_s_uk]

@T3P3Tony no, i just had M0 as the first line of the start code.
I didn't know macros could be broken out of but as its running the system stop.g, I wouldn't have thought this was required

[chrishamm]

Inconsistencies like this are very likely resolved in DSF 3.2-b2. If it still occurs with the next beta, please let me know.

[docbobo]

In that context: what would be the right way to cancel a print from within start.g?

[chrishamm]

@docbobo It depends if you want to pause the print first. If you only want to cancel it, M0 or M1 should be sufficient in start.g. If you want to pause it first, call M226 before M0/M1. I think that will define if stop.g/sleep.g or cancel.g is called, too.