Still problems with messages in DWC

darookee

I still have the problem with the Duet sending 'old' messages to the DWC

In the example below I sent M122 right after starting the Duet, before recording this, and got the correct response. After this I send M81, wich normaly does not return anything, just displays a green row in the G-Code console, but I get the M122 response back again. I also checked in the Chrome developer tools network console and it is the Duet that returns this. This does make debugging a big problem because I only get the correct output once per restart…

I already tried checking and unchecking the 'Log any successful G-Code' option and cleared the 'Cached File Information', though I don't think that would have anything to do with it, without success.

Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.20beta8+1 (2017-11-18)
WiFi Server Version: 1.20b9
Web Interface Version: 1.19.3

KeeganB

I get this same behavior occasionally as well. It really through me for a loop when selecting a file to print because it kept reporting that it was printing the file name of the last file I printed.

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!