Meta gcode result variable inconsistent with docs

[T3P3Tony]

@NineMile In the short term we need to update the documentation to more correctly describe what "Cancel" does when its pressed. We need to discuss what the impact will be on existing users who are relying on cancel to abort the macro/job if we change it not to do that as a work around for your requirement you can use this

echo { "Input: " ^ input }M291 P{"Blah, unimportant."} R"Big Title" S4 K{"Yes","No","Cancel"} T0 
echo { "Result: " ^ result }
echo { "Input: " ^ input }

[dc42]

@NineMile I think the documentation meant to say Cancel instead of Close. As to it aborting instead of returning -1 I can think of a few possibilities:

1. Change it to return -1 instead of aborting the macro. As Tony says, this might break macros for some users.
2. Change the M291 J parameter so that J1 aborts if Cancel is pressed as now, but J2 sets result to -1 instead.
3. Leave the behaviour as now but add some sort of exception-catching mechanism to meta GCode.

[T3P3Tony]

@NineMile if you don't mind please raise a feature request for the J2 option as @dc42 suggests

[NineMile]

@T3P3Tony said in Meta gcode result variable inconsistent with docs:

@NineMile if you don't mind please raise a feature request for the J2 option as @dc42 suggests

Done - the J2 option looks like a nice, clean way to implement both behaviours without breaking existing code.

[NineMile]

@dc42 I've been looking at implementing this and I have the J2 functionality working as described - however this also means that a J2 message box that times out will also return -1 (as well as if the user clicks Cancel).

I think this is the right behaviour, as in both cases it essentially means 'user did not supply a valid input', but I'd like to confirm that this is what you'd expect to happen as well.

I've tested on my stm32 based board and it works well - I have a Mini 5+ here that I'll test on once I get the build repo working. Happy to submit a PR for this if you'd like to look at the approach I've taken and verify I'm on the right track

[dc42]

@NineMile I was about to start implementing this, but your implementation may save me some time. If your code changes are ready, please share them.

Did you test them in SBC mode, or standalone mode, or both?

[NineMile]

@dc42 said in Meta gcode result variable inconsistent with docs:

@NineMile I was about to start implementing this, but your implementation may save me some time. If your code changes are ready, please share them.

Did you test them in SBC mode, or standalone mode, or both?

@dc42 I submitted a PR with the changes here.

I've tested in standalone mode only, currently on an stm32h7 board but the PR cherry picks the changes onto the duet branch. I can test standalone on a Mini 5 plus if necessary but I don't have a viable setup to run SBC mode for testing right now.

[T3P3Tony]

@NineMile have you tested this in stand alone mode with the latest build here:
https://www.dropbox.com/scl/fo/ga0jqwfksechhukg2uiz8/AOV3DR8z1C0UWczc8Rx25gE?rlkey=4saeh9luddndvxbhb0kdaqugr&dl=0

[NineMile]

@T3P3Tony said in Meta gcode result variable inconsistent with docs:

@NineMile have you tested this in stand alone mode with the latest build here:
https://www.dropbox.com/scl/fo/ga0jqwfksechhukg2uiz8/AOV3DR8z1C0UWczc8Rx25gE?rlkey=4saeh9luddndvxbhb0kdaqugr&dl=0

I've been using the stm32 beta.2 release which has been working great. While I have a Duet 5 for testing this isn't currently in any active setup of mine so I haven't tried specifically with those builds yet.

[T3P3Tony]

@NineMile thanks!