Odd behavior of M292 or maybe M291

mikeabuilder

Not sure if this is a bug, or undocumented behavior, or something new for me to understand.

I'm writing a macro where the user is asked for a lot of input via M219 commands. All is working well. The last line of my macro echos a macro-finished message. On the console, An M292 message is printed along with my exit message for every M291 that was used. I'm not sure why all these messages should be going to the console only if a future echo command is issued.

I've stripped down my macro and did some testing and it appears that there are M292 messages "buffered" and on the next echo command in the macro, they all get sent to the console.

Here's my repro case, and console output.

echo "start echo test"
M291 S4 K{"2", "5", "20", "50", "100", "Done"} T0 P"Select radius to include."
M291 S4 K{"20", "50", "100", "200", "300", "500", "Done"} T0 P"Select speeds to include.  300 is printer default"
M291 S4 K{"500", "1000", "5000", "10000", "Done"} T0 P"Select accelerations to include.  10000 or 1000 is printer default"

echo "middle of test"

M291 S4 K{"1", "10", "25", "50", "Done"} T0 P"Select jerk value to include.  10 or 25 is printer default"
M291 S4 K{"8", "16", "32", "64", "128", "256",  "Done"} T0 P"Select micro_steps value to include.  16 is printer default"
M291 S4 K{"2200", "1800", "1200", "800", "Done"} T0 P"Select max motor_current value to include.  2200 is printer default"
echo "end of echo test

4/28/2025, 8:28:07 AM 	M292 R{1} S144
                        end of echo test
4/28/2025, 8:28:07 AM 	M292 R{4} S143
                        end of echo test
4/28/2025, 8:28:07 AM 	M292 R{2} S142
                        end of echo test
4/28/2025, 8:28:04 AM 	M292 R{1} S141
                        middle of test
4/28/2025, 8:28:04 AM 	M292 R{2} S140
                        middle of test
4/28/2025, 8:28:04 AM 	M292 R{3} S139
                        middle of test
4/28/2025, 8:28:00 AM 	M98 P"0:/macros/data/echo_test.g"
                        start echo test

dc42

@mikeabuilder we need some more info:

What device are you using to display and respond to the M291 commands: DWC, or PanelDue?
If DWC, are you running the Duet in standalone or SBC mode?
What firmware version are you using; and is DWC (and DSF if running in SBC mode) the same version?

mikeabuilder

My Bad. I should have included my HW info.

Display device is DWC. I also have a PanelDue 7i on this machine, and I just tested launching the macro from it. When I do, only my echo messages appear on the PanelDue console, none of the M292 messages.
Duet board is MB6HC and is stand alone.
RRF and DWC are both 3.6.0-rc.2

dc42

@mikeabuilder I've asked @chrishamm to take a look at this.

chrishamm

@mikeabuilder The behaviour you're describing can be expected in standalone mode. The reason is that RRF does not return responses for each specific G-code request yet even though this is planned: https://github.com/Duet3D/RepRapFirmware/issues/925 We should be able to implement it in version 3.7 or 3.8.

I just changed the message box code in DWC 3.6 to avoid waiting for G-code replies of M292. This effectively fixes the issue you described in standalone mode, but I will not port it to newer versions because of the FR I mentioned. This is not an issue in SBC mode because the API is different - matching G-code replies are already returned there as part of the HTTP response.

chrishamm created this issue in Duet3D/RepRapFirmware

open Return full code reply via HTTP rr_reply code for corresponding rr_gcode calls #925

mikeabuilder

@chrishamm - thanks for the response and the github pointer. I took a look at the description and see it's just the same as what I found. Some of the description is beyond my knowledge, but it's good to know I'm only 2 years behind the leading engineers in finding things.