[3.4rc1] Issue with M291 in start.g

dc42

@oozebot we've just found and fixed an issue that could result in a M291 S2 or S3 message not being shown, if a M291 S1 message was previously closed in DWC before it timed out. See https://forum.duet3d.com/topic/27360/3-4-0rc1-dwc-and-rrf-feedback-bug-report/13 for new DWC builds to fix this.

oozeBot

@dc42 @chrishamm - I just installed Duet Web Control 3.4.0-rc2pre and are still seeing issues when calling M291 within conditional gCode. When run, the M291 from the below snippet isn't showing up in DWC or the PanelDue.. the system just reads "busy".

;==========================================================================================
;== Power Toggle ==========================================================================
M400        ; Wait until idle
if boards[0].vIn.current > 23
	M291 S3 R"Turn off power?" P"Are you sure you want to turn off power?"

chrishamm

@oozebot Is this macro called from a print file or anywhere else? Can you get the output of M122 when it gets stuck in "busy" state? The same macro works without problems on my setup.

oozeBot

@chrishamm The issue was first observed when calling an M291 from start.g at the beginning of a job, but in this case I'm simply running the snippet directly as a macro. Here is M122 when stuck in the busy state.

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0rc1 (2022-02-09 10:28:13) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-9P63L-DJ3T8-6J1FD-3SN6R-9V7RA
Used output buffers: 2 of 40 (26 max)
=== RTOS ===
Static ram: 150984
Dynamic ram: 65348 of which 176 recycled
Never used RAM 131308, free system stack 200 words
Tasks: SBC(ready,0.6%,506) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,772) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,7.4%,92) MAIN(running,89.4%,923) IDLE(ready,2.6%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:15:14 ago, cause: software
Last software reset at 2022-02-18 08:29, reason: User, GCodes spinning, available RAM 131524, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 134
MCU temperature: min 42.0, current 42.2, max 43.7
Supply voltage: min 23.9, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/7, heap memory allocated/used/recyclable 2048/90/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: pos 0, standstill, SG min 0, mspos 8, reads 14319, writes 14 timeouts 0
Driver 1: pos 0, standstill, SG min 0, mspos 8, reads 14323, writes 11 timeouts 0
Driver 2: pos 0, standstill, SG min 0, mspos 8, reads 14320, writes 14 timeouts 0
Driver 3: pos 0, standstill, SG min 0, mspos 8, reads 14320, writes 14 timeouts 0
Driver 4: pos 0, standstill, SG min 0, mspos 8, reads 14323, writes 11 timeouts 0
Driver 5: pos 0, standstill, SG min 0, mspos 8, reads 14320, writes 14 timeouts 0
Date/time: 2022-02-18 08:44:20
Slowest loop: 1304.36ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters 2 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0 70 0, running macro
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== Filament sensors ===
Extruder 0 sensor: no filament
=== CAN ===
Messages queued 9025, received 19482, lost 0, boc 0
Longest wait 3ms for reply type 6026, peak Tx sync delay 40428, free buffers 50 (min 49), ts 4571/4557/0
Tx timeouts 0,0,13,0,0,0 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 4, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 40250/40250
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0, IAP RAM available 0x2bca8
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4-rc1
HTTP:
Waiting for acknowledgement, requested by M291 S3 R"Turn off power?" P"Are you sure you want to turn off power?"
> Next stack level
Executing macro 0:/macros/test3.g, started by M98 P"0:/macros/test3.g"
> Next stack level
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 44.08, max time between full transfers: 74.1ms, max pin wait times: 46.3ms/6.4ms
Codes per second: 0.08
Maximum length of RX/TX data transfers: 3164/548

chrishamm

@oozebot Thanks, that looks normal to me. Do you see any error messages in the JS console (open via F12) and is the state.messageBox value in the object model explorer a valid object when the message box is supposed to be shown?

oozeBot

@chrishamm There are no errors in the JS console. As far as "looking normal", the snippet below sticks out to me. It knows it's waiting on acknowledgement, but the message box is never displayed.

I just did another test. I simply ran M291 S3 R"Test" P"Test" from the "Send Code.."box across the top. It resulted in the same results - the system is stuck in busy with no messagebox displayed.

edit - this was tested in both Chrome and Edge with the same results.

If you can think of any other test you'd like me to perform, I have a machine free specifically for testing. Thanks

=== Duet Control Server ===
Duet Control Server v3.4-rc1
HTTP:
Waiting for acknowledgement, requested by M291 S3 R"Turn off power?" P"Are you sure you want to turn off power?"
> Next stack level
Executing macro 0:/macros/test3.g, started by M98 P"0:/macros/test3.g"

chrishamm

@oozebot Can you please downgrade RRF to 3.4-b7 and check if the message boxes work then? I am not aware of any change that could break this feature and being unable to reproduce it myself doesn't make it any easier.

oozeBot

@chrishamm @dc42 - reverting to RRF 3.4b7 resolves the issue. The message boxes are properly displaying.

dc42

@oozebot are you able to temporarily run that test machine in standalone mode using 3.4rc1+2 and see whether the issue still occurs?

PS - here's another test you can do. Connect a PC running YAT or another terminal emulator to USB. Send this command to it:

m409 k"state.messageBox"

It should return:

{"key":"state.messageBox","flags":"","result":null}

Now run a macro containing the code snippet you posted. When the message box is supposed to be displayed, send the M409 command via USB again. This time it should respond:

{"key":"state.messageBox","flags":"","result":{"axisControls":0,"message":"Are you sure you want to turn off power?","mode":3,"seq":7,"timeout":0,"title":"Turn off power?"}}

Sending M292 will clear the result back to null. The "seq" value in the response should increment each time you run the macro.

MaxGyver

@dc42

I ran the test, but since I am using an SBC I was unable to run a macro. Sending the M291 from the terminal did not return the expected response.

M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.4.0rc1+2 ELECTRONICS: Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_DATE: 2022-02-17 15:38:02<LF>ok<LF>
m409 k"state.messageBox"
{"key":"state.messageBox","flags":"","result":null}<LF><LF>ok<LF>
M291 S3 R"Turn off power?" P"Are you sure you want to turn off power?"
- Turn off power? -<LF>Are you sure you want to turn off power?<LF>Send M292 to continue or M292 P1 to cancel<LF>ok<LF>
m409 k"state.messageBox"
{"key":"state.messageBox","flags":"","result":null}<LF><LF>ok<LF>

MaxGyver

@dc42 @chrishamm

I just switched to standalone mode. Here, M291 works flawless.

dc42

@maxgyver said in [3.4rc1] Issue with M291 in start.g:

@dc42 @chrishamm

I just switched to standalone mode. Here, M291 works flawless.

Thanks, that's useful information.

oozeBot

@maxgyver - Thank you for testing this. We had it on our agenda to test this morning..

@dc42 - Please let us know if there is anything else you need us to test as we have a dedicated test machine.

dc42

@oozebot please can you try downgrading RRF only (not DWC or DSF) to 3.4.0beta7, and see if the problem still occurs. You should be able to do that by uploading the firmware binary through DWC, and then running M997 if it doesn't prompt you to install it.

oozeBot

@dc42 - maybe you missed my response to this on Friday. Only RRF was downgraded.

@oozebot said in [3.4rc1] Issue with M291 in start.g:

@chrishamm @dc42 - reverting to RRF 3.4b7 resolves the issue. The message boxes are properly displaying.

dc42

@oozebot thanks. Can you conform that you were using the latest DWC build (later than the rc1 build) when you ran this test?

dc42

@MaxGyver @oozeBot please try the new Duet3Firmware_MB6HC.bin at https://www.dropbox.com/sh/2dt7sbqpx6l74np/AADn4-lpcil1iqnWKkiVri3Ia?dl=0.

oozeBot

@dc42 It appears to be working in 3.4.0rc1+3, however, we'll keep testing and report back with any issues. Thanks!

oozeBot

@dc42 While M291 is now working in 3.4.0rc1+3, the prompt has stopped showing up on the PanelDue (3.4.1-pre1). With 3.4.0rc1, the prompt was only displaying on the PanelDue.. We'll do some more testing, but this can be reproduced pretty easily.

oozeBot

The reported M291 issue within DWC appears to be resolved with the pre-release provided earlier today. The issue with the message box displaying on the PanelDue appears to be intermittent and independent of this issue.