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 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!