DWC 3.2-RC1: Interface becomes unresponsive / Requires a refresh

CCS86

Problem persists with 3.2-RC1

Phaedrux

Can you please provide the results of M122 as well?
What Duet are you using? Firmware version?
How did you update?

CCS86

Duet Maestro running RRF 3.2-RC1. Updated via the DWC uploader.

=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 3.2-RC1 running on Duet Maestro 1.0
Board ID: 08DJM-956DU-LLMS4-7J9F6-3SN6Q-KBM2Q
Used output buffers: 3 of 24 (22 max)
=== RTOS ===
Static ram: 22292
Dynamic ram: 66740 of which 72 recycled
Never used RAM 25728, free system stack 150 words
Tasks: NETWORK(ready,198) HEAT(blocked,332) TMC(blocked,117) MAIN(running,458) IDLE(ready,20)
Owned mutexes:
=== Platform ===
Last reset 22:08:05 ago, cause: software
Last software reset at 2020-12-20 15:56, reason: User, GCodes spinning, available RAM 15696, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN Freestk 4294967295 ok
Stack: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 38.7, current 47.4, max 50.3
Supply voltage: min 0.0, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 0, standstill, read errors 0, write errors 1, ifcnt 77, reads 42681, writes 24, timeouts 0, DMA errors 0
Driver 1: position 0, standstill, read errors 0, write errors 1, ifcnt 77, reads 42681, writes 24, timeouts 0, DMA errors 0
Driver 2: position 12160, standstill, read errors 0, write errors 1, ifcnt 76, reads 42681, writes 24, timeouts 0, DMA errors 0
Driver 3: position 0, standstill, read errors 0, write errors 1, ifcnt 28, reads 42685, writes 20, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, read errors 0, write errors 1, ifcnt 13, reads 42699, writes 6, timeouts 0, DMA errors 0
Driver 5: position 0, assumed not present
Driver 6: position 0, assumed not present
Date/time: 2020-12-21 12:22:49
Slowest loop: 886.63ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 10.0MBytes/sec
SD card longest read time 2.3ms, write time 161.1ms, max retries 1
=== Move ===
DMs created 83, maxWait 55923909ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 20514, completed moves 20514, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 878.78ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 2 of 8
Interface state active, link 100Mbps full duplex

Phaedrux

I would start with a fresh SD card, copy over your macros and sys folder and create the /www folder fresh from the DWC zip release and see if the problem persists.

CCS86

@Phaedrux said in DWC 3.2-RC1: Interface becomes unresponsive / Requires a refresh:

This is actually a fairly fresh SD card and install. But, something could certainly have gotten borked.

I never had this issue on RRF 3.1.1 / DWC 3.1.1. It started right when I installed 3.2B4 of both.

If it really couldn't find those files, a browser refresh doesn't seem like it would fix the error.

CCS86

I updated to RC2.

The background unresponsiveness continues. Maybe Chrome does something to "idle" the tab when it isn't active, and DWC doesn't like it?

I am seeing new console errors that don't clear with a refresh:

Phaedrux

What version of chrome? What OS?
Have you tried with another browser yet?

CCS86

@Phaedrux

Win 10 Pro 19042.685
Chrome Version 87.0.4280.88

MS Edge shows the same first error. Haven't seen if it replicates the unresponsiveness yet, but I can check:

Even when the DWC page is unresponsive to mouse clicks, and shows the darkened overlay, the temperature readouts are still live, and if you use the keyboard buttons, you can tab around inside the DWC page.

chrishamm

Can you try out RC2?

Phaedrux

@CCS86 said in DWC 3.2-RC1: Interface becomes unresponsive / Requires a refresh:

I updated to RC2.

@chrishamm

CCS86

@chrishamm

Slightly different in RC2. Behavior is the same.

I can tab around the page, successfully send gcodes, change heater temp, and change the fan speed, etc sliders... all with the keyboard. The navigation pane / tree doesn't respond to this approach though. I can tab around in there and see an animation when I hit enter on an item. But, nothing happens.

oliof

I have this issue for many DWC releases now and one of the best workarounds I've found is to open DWC in a standalone window. I haven't been able to rule out my set of browser extensions as a source, so I haven't reported this as of yet.

chrishamm

@CCS86 Interesting, your JS console outputs something about index.js but DWC2 and later don't use that file at all. It probably won't harm to clear your browser cache once. I'll try to reproduce this problem in standalone mode but I'm afraid I won't find time for this before next week. I did fix a potentially related problem for SBC setups in RC2 though.

PS: The last few error messages could be generated by browser extensions too - try disabling them and check if it makes a difference.

CCS86

I did some more digging about that index.js error, and found it was being caused by the Kaspersky password manager plugin. So, that much is resolved. But, I don't think it is related to the unresponsiveness issue.

The only fresh reload console error I have now is:

(also, probably unrelated)