way to suppress connection notifications?
-
DWC 2.0.7 / Safari
I have a regular stream of "disconnected / attempting to reconnect" type notifications. The popups have no value and the console becomes unusable because too difficult to find the useful messages amongst this junk.
Is there a way to turn off notifications about connection status? (anyway it was always obvious if you're disconnected because everything greys out)
-
setup -> user interface -> notifications ?
-
this is what we have.... but if would affect ALL notifications
-
@r123 I agree, these notifications need to be removed or change how DWC determines it was disconnected. Simply minimizing the page on a Mac with Safari causes the disconnection messages and there can be dozens in the console, hiding much more important messages.
-
The underlying issue is: why are you getting so many disconnections?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 It may well be as mwolter mentions above, related to browser usage. I have webcontrol open in a Tab of Safari browser and am not "looking at" it all the time so the process may well sleep. Additionally my laptop may sleep too. And prints frequently run for 10-12hrs so that leaves plenty of room for disconnections.
My view is that disconnection info in the console might well be useful for debugging connection problems, to see for example if a change on the LAN improves connectivity. But the rest of the time am not sure it's useful at all. A preference would suit all comers (if adding a preference does not come at too high a cost).
-
btw. Safari browser has good reasons for putting the DWC process to sleep when not being looked at. The below CPU report is not atypical (DWC is http://192.168.0.247)
-
@r123 said in way to suppress connection notifications?:
@dc42 It may well be as mwolter mentions above, related to browser usage. I have webcontrol open in a Tab of Safari browser and am not "looking at" it all the time so the process may well sleep. Additionally my laptop may sleep too. And prints frequently run for 10-12hrs so that leaves plenty of room for disconnections.
No, that's not it. If the Duet is reporting disconnections, that means that it has lost communication with the access point. I suggest you take a look at https://duet3d.dozuki.com/Wiki/WiFi_disconnections_and_AJAX_timeout_errors.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
OK thanks, for some reason had the impression that the notification meant DWC / the browser had lost connection with the Duet.
Checking the article suggestions discover Max Ajax Retries was set to 2 (I didn't set it so must have been a historic default) and have upped it to 4 (greater than the minimum 3).
The MaxReps number sounds interesting and might easily be guilty of moving too fast / high steps rate. However in the Console readout with RRF 3.0 this number is not reported?
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 94, MaxWait: 1219589ms
Bed compensation in use: mesh, comp offset 0.050
=== MainDDARing === -
It occurred to me later that the AJAX setting probably has more to do with Duet <> browser connections than Duet <> router. Re-reading the webpage it's true that its moderately confusing as troubleshooting guides go because various kinds of disconnect are all considered together (of course sometimes the causes and cures may be the same, but nonetheless). Wonder again if it would work to make the Duet Help pages a WIKI so that engaged users can refine them over time?
Rebooted the wifi router as well to get a more propitious wifi channel (can get crowded with neighbours). Despite these two changes still getting plenty of disconnections. All I can say really is that have only been seeing this since upgrading to RRF3.0 and DWC 2.0.7.
And, there does SEEM to be a link with Safari tab usage. For example in the below console output between 21:46 and 21:52 I stared at the open tab (no timeouts), then just into 21:52 moved to another tab (this one!). Shortly after there was a timeout; and then another.
-
@r123 Could you try connecting with a different browser, and see if that continuously disconnects? I use Firefox, no problems here, though I seem to remember something similar happening to me with Safari.
Also, can you please post the full response from M122?
Ian
-
Apple and Safari are pretty aggressive with power saving measures.
See if this fix helps: https://apple.stackexchange.com/questions/280679/preventing-safari-background-tabs-disconnecting-from-server
-
@dc42 said in way to suppress connection notifications?:
@r123 said in way to suppress connection notifications?:
@dc42 It may well be as mwolter mentions above, related to browser usage. I have webcontrol open in a Tab of Safari browser and am not "looking at" it all the time so the process may well sleep. Additionally my laptop may sleep too. And prints frequently run for 10-12hrs so that leaves plenty of room for disconnections.
No, that's not it. If the Duet is reporting disconnections, that means that it has lost communication with the access point. I suggest you take a look at https://duet3d.dozuki.com/Wiki/WiFi_disconnections_and_AJAX_timeout_errors.
In my case the Duet (Duet 3) has not lost connection with the access point since it uses Ethernet and not WiFi. I had this issue with a Duet 2 Ethernet as well. I believe Safari is attempting to manage the resources of tabs out of focus and DWC interprets this as a disconnection. Btw my Mac is also on Ethernet and there are no network interruptions between it and the Duet.
-
Fair enough! Most of the reports we get of connections dropping out relate to Duet WiFi and low signal strength. But I've heard of additional issues when the browser is Safari.
-
Well, it's early days but have a lurking suspicion that this Safari Tab related behaviour only occurs when PRINTING. Not when the printer is idle.
Just ran a print that was SLOW (by my standards) and, despite putting the DWC Safari Tab into the background for much of the print, there were no timeout events.
Will have to perform this exercise more often to be sure but that's something to think about.
btw. here's the full M122 after the slow print @droftarts
As mentioned in an earlier post there's no MaxReps in the "move" section? (As mentioned in the connectivity debugging article above.)
m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917DA-G4MS4-6JKD2-3SD6N-TTYBA
Used output buffers: 5 of 24 (9 max)
=== RTOS ===
Static ram: 30516
Dynamic ram: 92764 of which 20 recycled
Exception stack ram used: 664
Never used ram: 7108
Tasks: NETWORK(ready,688) HEAT(blocked,1240) DUEX(suspended,160) MAIN(running,1420) IDLE(ready,156)
Owned mutexes:
=== Platform ===
Last reset 00:41:59 ago, cause: power up
Last software reset at 2020-03-21 14:03, reason: User, spinning module GCodes, available RAM 7816 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 60.3ms, max retries 0
MCU temperature: min 25.0, current 44.5, max 44.7
Supply voltage: min 23.9, current 24.2, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/1023
Driver 6: standstill, SG min/max 0/1023
Driver 7: standstill, SG min/max 0/1023
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-03-25 20:07:37
Cache data hit count 4294967295
Slowest loop: 87.05ms; fastest: 0.10ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 138, MaxWait: 204529ms
Bed compensation in use: mesh, comp offset 0.050
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 0
Stack records: 3 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 172.24ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address bc:dd:c2:9a:4a:80
WiFi Vcc 3.41, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 22448
WiFi IP address 192.168.0.247
WiFi signal strength -50dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 3 sensor: ok
- WiFi -
-
Were you able to try the link I posted?
-
@Phaedrux - thanks for the suggestion. I did read and note. However do think that Safari's power saving feature is a good thing. Certainly on battery power but also with power adapter connected to laptop it's saving processor cycles and so forth. Admit I'm a cheapskate who didn't fit a screen to his Duet / Railcore printer and so keeps the web interface running all the time that the printer is on. But most of the time the tab is in the background and, if it's sleeping, so much the better.
