Still problems with messages in DWC

[resam]

I already have this on 1.19.2.
I don't think I had this problem with 1.19.0 though…
Or maybe an upgrade from DWC1.19 to DWC1.19.2 is the root cause?

[darookee]

I had this for a while now, too, probably since 1.19, but I'm not entirely sure.

[Jarery]

I've also now encountered this but only since upgrading to the latest 1.20b8

[Alex9779]

https://github.com/chrishamm/DuetWebControl/issues/50
I created an issue for this a while ago but this got closed. I still have this problem. When doing some thing I don’t even get the latest messages but just old ones making it impossible to proceed without a restart.
I tried Chrome, Safari and IE but all the same…

Alex9779 created this issue 26 Jul 2017, 08:02 in chrishamm/DuetWebControl

closed G-Code console log messages weird #50

[resam]

Thinking about it, my problems only started when I upgraded from 1.19 to 1.20beta7.
After playing around with b7 I did a downgrade to 1.19 (by mistake) and then went to 1.19.2.
Around this time I also upgraded DWC from 1.19 to 1.19.3, unfortunately I can't remember when exactly…

Only then I started seeing this problem.
I still have it with RRF1.19.2 & DWC1.19.3.

[Alex9779]

But on my PanelDue all is fine, except that long messages get truncated…
Think Chris is right that it may be a firmware issue, maybe David can have a look at this?

[dc42]

There is a known issue with DWC messages getting replicated, triggered by connecting 2 browers to the Duet and then disconnecting one of them.

[resam]

I just tested this with wireshark attached, and it also happens with a single browser.
I see the following responses to the [c]/rr_reply[/c] request (in order):

File /gcodes/lithophane-light-mount.gcode selected for printing\n
 

File /gcodes/lithophane-light-mount.gcode selected for printing\n
\n

File /gcodes/lithophane-light-mount.gcode selected for printing\n
\n
\n
 
 

File /gcodes/lithophane-light-mount.gcode selected for printing\n
\n
\n
Leadscrew adjustments made: 0.008 -0.025, points used 2, deviation before 0.013 after 0.000\n
\n

File /gcodes/lithophane-light-mount.gcode selected for printing\n
\n
\n
Leadscrew adjustments made: 0.008 -0.025, points used 2, deviation before 0.013 after 0.000\n
\n
 
 

File /gcodes/lithophane-light-mount.gcode selected for printing\n
\n
\n
Leadscrew adjustments made: 0.008 -0.025, points used 2, deviation before 0.013 after 0.000\n
\n

File /gcodes/lithophane-light-mount.gcode selected for printing\n
\n
\n
Leadscrew adjustments made: 0.008 -0.025, points used 2, deviation before 0.013 after 0.000\n
\n
 
```
So this seems to be a buffer getting concatenated with old data and not getting emptied correctly.

[resam]

Thinking about it some more, I actually have a Cura plugin to upload & send G-Codes.
This might be "a second browser"… I will update the plugin to send a [c]/rr_disconnect[/c] to properly close the session.
I will report back once I tested this.

[Alex9779]

Ok that with two browsers is new to me…
I have reachability checks and an auto power off with NodeRed implemented after 30 minutes idle.
This check run with HTTP so this might be the second browser...

[Alex9779]

Hmmmmmm seems I got this fixed for me…
Inserted a /rr_disconnect GET request just after I get the status and now it seems working without old log messages. I just get in return what should be returned...

Thanks for the hint! There are so many aspects and stuff to look at and to have in mind. Thank god David knows all this

[darookee]

Well, that is interesting. It seems to be fixed for me, too. I added a call to '/rr_disconnect' in the script that pulls the printer status and it looks like the problem is solved. Thanks!