M291 - some behavior not matching documentation

mikeabuilder

RRF 3.5 beta 2
PanelDue fw 3.4.1
HW Duet2 Wifi

I've just experienced some odd behavior with M291 messages. I looked in the release notes and saw several M291 items but none match my experience today.

Here's a snippet of code from a macro that gives the user 10 seconds to opt out of homing all axes:

var delay = 10
; HOME ALL AXES
set var.now = +state.time
M291  S2 T{var.delay}  P"Prep Step 2 of 4  - HOME ALL AXES: To skip, press OK within 10 seconds."
if +state.time - var.now > var.delay-1
  M291 S1  T999 P"Homing all axes."
  ;M291 S2  T1 P"Homing all axes."
  ;M291 S1  T999 P"Next message"    
  m98 P"0:/sys/homeall.g"
  G4 P0   ; wait for homing to finish before moving on to the next step
  M291 S1  T1 P"Homing completed."
else
  M291  S1 T20  P"Axes homing skipped per user request. "
  M118 L2 S"Axes homing skipped per user request. "

Issue #1 - The gcode dictionary for M291 with S=2 (as on line 4) says is the T parameter will be ignored (because S=2 is blocking). In practice, after 10 seconds, execution is unblocked. I am using this as a "feature" to make my macro work, but it seems wrong.

The way my macro works, the test in the if on line 5 only evaluates to true if the user does not select "OK" within 10 seconds. When this happens, the message on Line 6 should replace the prior message and stay on screen until homing is complete and the message on line 11 pushes it off the queue. It does this on DWC, but not on PanelDue.

Issue 2 - On PanelDue, the line4 message remains displayed even though RRF has moved on and is performing the homing action. The Line 6 message is never displayed.

And in our process of trying to understand the behavior, we replaced the line 6 with the version on line 7, thinking maybe an S=2 message would push the previous message where an S=1 message would not. The behavior remained the same. We tried this with T=1 and also T=999.

Then we added line 8. With line 7 and 8 both enabled (and line 6 commented out), the message on Line 7 appeared on Panel Due and remained until the message on line 11 replaced it. It seems that Line 7 message unblocked after 1 second, and the message after it caused it to remain on-screen on PanelDue.

Very strange.

OwenD

@mikeabuilder
I can confirm that the T parameter does indeed close what should be a blocking message (S2 & S3)
I'm undecided whether that should be considered a bug or a feature

I don't think the PanelDue firmware has been updated to include all the 3.5b2+ functionality yet, so that might explain the difference to DWC

droftarts

@OwenD said in M291 - some behavior not matching documentation:

I don't think the PanelDue firmware has been updated to include all the 3.5b2+ functionality yet, so that might explain the difference to DWC

It's on the 'to do' list! https://github.com/Duet3D/PanelDueFirmware/issues/assigned/mfs12

Ian

mikeabuilder

@OwenD - your comment on bug vs feature is right on for S=2 (display an OK button), and my macro uses that behavior. The behavior I'm using is not available in any of the documented modes. From a specification perspective, I want a blocking message that unblocks on either an "OK" user response or the expiration of a timeout duration. As specified in the gcode docs, none of the modes support this behavior.

If I were writing the spec for message modes, I would have these rules (for messaging between RRF and displays) regarding the T parameter:

For modes that are non-blocking (S=0 or S=1) - these are just to be thorough:

The display is instructed to show the message for the duration specified with the T parameter.
If T <=0, RRF will substitute the default duration of 10 seconds.
RRF will continue to execute gcode after sending the message to the display. (This is the definition of non-blocking)
The display will stop showing the message IF (the user closes the display window) OR (RRF sends a subsequent message to display). This is the queue referred to in the release notes for 3.5 beta2

For modes that are blocking and can have only one response (S=2):

The display is instructed to show the message for the duration specified with the T parameter, if one is provided and <=0.
If T >0, RRF will wait for an m292 response from the display for the specified duration, then assume an "OK" response from the display and resume gcode execution. This is the current, incorrect behavior.
If RRF has a subsequent message to display, it will not send a message to the display instructing it to terminate the existing message until the time period T expires. This is needed to preserve the blocking nature of the mode.

For modes that are blocking and can have multiple responses from the display (S>=3):

The display is instructed to show the message for the duration specified with the T parameter, if one is provided and <=0.
If T >0 AND an L parameter is provided, RRF will wait for an M292 response from the display for the specified duration, then use the default parameter. If T is supplied but not an L parameter, T is assumed to be 0 and a WARN message issued. For S=3, the L parameter would need to be supported, with L = "OK" or "CANCEL".
If RRF has a subsequent message to display, it will not send a message to the display instructing it to terminate the existing message until the time period T expires. This is needed to preserve the blocking nature of the mode.

Also note that in the definition of T in the cgode dictionary, it says A zero or negative value means that the message does not time out , but RRF 3.5beta2 throws an error for negative values of T.

This M291 command is getting really complicated. It would be helpful to me (maybe others?) if the a more structured description of the rules was described, as my feeble attempt above. In digging into this issue, it's helped me to think of RRF as the control, but DWC and PanelDue as independent players using a defined communication protocol. A new doc page showing how (and when) the players communicate would help me, and maybe others too.

T3P3Tony

@mikeabuilder

Referenced in this github issue:
https://github.com/Duet3D/RepRapFirmware/issues/738

T3P3 created this issue in Duet3D/RepRapFirmware

closed M291 S2 not unblocking/Unblocking after timeout. #738

T3P3Tony

@mikeabuilder for the PanelDue issues mentioned, please test with the latest release and report there:
https://forum.duet3d.com/topic/32309/paneldue-firmware-3-5-0-rc4-released

mikeabuilder

The issue (#2) reported with PanelDue at the beginning of this thread is not present in the 3.5 beta4 PanelDue fw.

mfs12

@mikeabuilder said in M291 - some behavior not matching documentation:

Issue #1 - The gcode dictionary for M291 with S=2 (as on line 4) says is the T parameter will be ignored (because S=2 is blocking). In practice, after 10 seconds, execution is unblocked. I am using this as a "feature" to make my macro work, but it seems wrong.

So i conclude this is still present in PanelDue 3.5.0-rc4 and RRF 3.5 beta 2?

@dc42 do you agree that this should be ideally fixed in RRF, in that way RRF doesn't send the timeout in the first place?

mikeabuilder

Yes, Issue #1 is still present., and I see @T3P3Tony added it to github. I'm not sure precisely how the code works between RRF and multiple UIs (PanelDue or DWC), but I guess that RRF unblocking (proceeding to process subsequent commands) at the end of the timeout period happens without an M292 response from a UI. This means the T parameter has 2 functions - one is how long the UI should display a message, the second is how long RRF will wait for an M292 response.

In my opinion, it should be preserved as a feature. Making S2 fully blocking could easily be done by setting T=0 or having no T parameter.

dc42

@mikeabuilder I have updated the documentation and we have adjusted the behaviour to match it in RRF 3.5.0-beta.4. The general rule is:

For a blocking message, timing out is equivalent to the user pressing the Cancel button
Therefore, a blocking message can only have a timeout if it also has a Cancel button.