Unresponsive web interface

I have just completed my first Ormerod build and successfully printed the snowman (more or less). Some adjustments need to be done of course. But what I do find is the web interface being extremely unreliable. Currently it's being more or less completely unresponsive. Sometimes I'm able to open up the web interface and hit the connect button but soon after it freezes and when I try to reload the page it's like the other end isn't responding. I'm still able to use pronterface when this happens though.

I've made sure the assigned IP address does not collide with anything else. What could be the cause of this?

Which versions of the firmware and the web interface are you using?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Duet firmware 0.78.
Not sure where I can see the web version? But it was the www folder in the master zip file containing firmware 0.78 if that's any help?
In the serial console I also see the message "Network connection error, code -10" every second.

The web server version should be displayed on the Settings tab of the web interface.

You might like to try my 0.78h firmware here [github.com] (follow the link and then press Raw to download) and web interface 0.98 here [github.com]. The firmware still uses the same low-level network code (LWIP), but the web server and middle layers have been largely rewritten to improve speed and reliability. You can find a full list of differences at [github.com].

Edited 1 time(s). Last edit at 08/08/2014 07:40AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

That's where I found the duet firmware version. Can't find any version information about the web interface there. I might very well try your firmware later, thanks!

Now, when the final layers of the whistle was printing I accessed the web interface from another client (my phone). First the page loaded fine and then it all froze and when I went to the printer to see what happened it was at a complete stop and inaccessible. Had to cut the power. It's not like it happens seldom but very often so I can't be the only one experience this, right?

Quote
bitfield
Now, when the final layers of the whistle was printing I accessed the web interface from another client (my phone). First the page loaded fine and then it all froze and when I went to the printer to see what happened it was at a complete stop and inaccessible. Had to cut the power. It's not like it happens seldom but very often so I can't be the only one experience this, right?

Hello bitfield, I experienced similar problems as you described during the initial stages of my printing. I Initially thought it might have to do with my network but after a firmware upgrade to one of dc's latest versions my problems disappeared

Quote
bitfield
Now, when the final layers of the whistle was printing I accessed the web interface from another client (my phone). First the page loaded fine and then it all froze and when I went to the printer to see what happened it was at a complete stop and inaccessible. Had to cut the power. It's not like it happens seldom but very often so I can't be the only one experience this, right?

As i said in the other tread i had this problem with an earlier version of the firmware. I had not seen it with dc42's dev branch until last night when it happened to me almost exactly as you described. I cant be 100% sure i didn't click the estop instead of the connect so i didn't think i would bring it up unless it happened again.

Although i didn't dry to connect from a different device i connected with the same device on a different subset (broadcast domain). I have also had problems accessing the web interface from this separate sub net even though there is no Nat or firewall in between. i install the chrome equivalent of firebug tomorrow and try and work out if its a network issue or something to do with the duet

The dc42 version seems a lot more stable! And by the looks of it, it seems to be able to track the print as well (which the original web didn't for some reason). I'm about to start a print and see how it goes.

Unfortunately, the dc42 version suffers from the same symptoms now. I've been printing more frequently last couple of days and the web interface becomes completely dead every now and then. When it happens I have to cut the power. The web server simply doesn't respond. Is this something others experience as well or might there be something wrong with my Duet? Sometimes I can't even manage to start a print and sometimes it dies after the first or second print. Sometimes during print (but that seems to be more seldom). It's pretty frustrating. Please note that any ongoing print continues. It's just the web interface that isn't responding.

I'm currently running dc42 firmware 0.78h and web interface 0.98.

Edited 1 time(s). Last edit at 08/23/2014 02:14PM by bitfield.

Quote
bitfield
I have just completed my first Ormerod build and successfully printed the snowman (more or less). Some adjustments need to be done of course. But what I do find is the web interface being extremely unreliable. Currently it's being more or less completely unresponsive. Sometimes I'm able to open up the web interface and hit the connect button but soon after it freezes and when I try to reload the page it's like the other end isn't responding. I'm still able to use pronterface when this happens though.

I've made sure the assigned IP address does not collide with anything else. What could be the cause of this?

I had this trouble when I tried connecting with Firefox - some buttons did not respond.
Use Chrome, as that seemed trouble free.

---

Ormerod #17

You misunderstood me. It's not that the UI itself is unresponsive. It's rather that the entire server doesn't respond. The title might be misleading. And I've only been using Chrome btw, (and tested some with Safari as well). In the status field of chrome it's just saying "Connecting ..."

Edited 1 time(s). Last edit at 08/23/2014 03:13PM by bitfield.

Yes, I frequently get LAN disconnects as well. It doesn't bother me too much because once I've started a print I don't need it except as a minor convenience. It seems to need a Duet reset to get it connecting again (which obviously cannot be done during a print!). Due to the fact that I'm not that bothered by it, I have not done any debug, and there is no obvious pattern to it (it does not appear to be related to LAN traffic load). One of these days I'll have WireShark running when it disconnects, and DC42 may be able to get his teeth into the issue, though it really needs a trace from the Duet side rather than the PC side, and that's not easy to arrange when going through a normal Ethernet switch - it needs a direct connection (which sod's law says will then work reliably). Intermittent bugs like that are a real PITA to track down.

Dave
(#106)

There is still a networking issue in RRP's and dc42's firmware forks, and it's possible this issue is somehow related. My firmware fork already contains a potential fix, so it would be interesting to know if this issue also occurs with my latest firmware release. Is anyone willing to give it a try and report if this problem persists? If it does, I'd appreciate a Wireshark dump so I can take a look again.

Quote
zombiepantslol
There is still a networking issue in RRP's and dc42's firmware forks, and it's possible this issue is somehow related. My firmware fork already contains a potential fix, so it would be interesting to know if this issue also occurs with my latest firmware release. Is anyone willing to give it a try and report if this problem persists? If it does, I'd appreciate a Wireshark dump so I can take a look again.

Which Web interface does your firmware need, and I'll give it a try?

Dave
(#106)

You may use either my web interface fork (https://github.com/zombiepantslol/OrmerodWebControl) or dc42's web interface. My latest 0.89f release should be compatible to dc42's 0.99 web interface as well.

I am having page loading problems on some PC's and on others it just works...
Only parts of the web page seem to be received, the browser shows half a page.

I have a wireshark log of downloading the page on working and nonworking PC's,
the received packets on the working PC are all 1486 bytes long, and on the non
working PC the packets seem to be missing data...?

Since the log files also contain packets of the company network
I can't post them here, if you want more info please let me know!

Edited 1 time(s). Last edit at 08/26/2014 06:17PM by 3D-ES.

---

RS-Online Ormerod #263, Kossel mini with Minitronics, Prusa i3 MK2

Quote
zombiepantslol
There is still a networking issue in RRP's and dc42's firmware forks, and it's possible this issue is somehow related. My firmware fork already contains a potential fix, so it would be interesting to know if this issue also occurs with my latest firmware release. Is anyone willing to give it a try and report if this problem persists? If it does, I'd appreciate a Wireshark dump so I can take a look again.

I would like to test this, but I won't see my printer until thursday

---

RS-Online Ormerod #263, Kossel mini with Minitronics, Prusa i3 MK2

Hi 3D
When you capture the traffic in wireshark you can apply a filter, for example "eth.addr == 00:15:17:7a:50:48" and this should only capture traffic from/to this device and leave your company traffic out of the capture. Obviously, substitute your printers MAC address and not the one above for my PC

Ok, sorry got that wrong, its a display filter, you need to apply the filter at the "save as" point, you can press the "displayed button" when saving. then reload the file to make sure only the printer packets are saved in the file. You should be able to load the already captured file, apply the display filter and then resave the file after pressing the "displayed" button.

Edited 1 time(s). Last edit at 08/27/2014 04:27AM by ezwul.

Quote
ezwul
Hi 3D
When you capture the traffic in wireshark you can apply a filter, for example "eth.addr == 00:15:17:7a:50:48" and this should only capture traffic from/to this device and leave your company traffic out of the capture. Obviously, substitute your printers MAC address and not the one above for my PC

You can also filter by IP address, which is what I do.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

yes, but IP capture wont get the ICMP broadcast messages, such as ARP etc.
If the connection is dying due to network issues you will miss these.
For level 3 debugging IP is suitable I was trying to get you all the info from the existing capture.

@ezwul:

I tried to filter the log, but I could not find the "displayed button" when using save-as,
my version of Wireshark is probably different from yours, or I don't understand you...?

@zombiepantslol:

The firmware changes you made do not seem to be related to this problem,
the page loading problem is exactly the same as with dc42's firmware version.

@everybody who likes to look at packet capture log files:

I have made a new log file with only the Ormerod and my laptop connected,
the half loaded webpage of the Ormerod always ends after the text "div class="

FW Version: RepRapFirmware-078k-dc42.bin with web version 0.99

I should have tried the latest firmware revision, I will do that tomorrow!

---

RS-Online Ormerod #263, Kossel mini with Minitronics, Prusa i3 MK2

3D-ES

The picture attached shows the button to press to only save the displayed packets, I have uploaded this so as to not leave any loose ends to this thread.
This is from the Linux Wireshark, but I am positive that it is also there for a windows release.
You need to have a display filter in place first to remove unwanted packets. I use "eth.addr == be:ef:de:ad:fe:ed" to filter packets to/from my Ormerod, but "ip.addr == 192.168.2.20" would also suffice as DC mentioned.
Once, only the packets you need are displayed then you can use "save as" and press the "displayed" button and it will show you the count of packets it will save below, before continuing and completing the save with the "save" button, obviously you need to have a filename in the "name" text box.

This can be also be done on captured files, "open" the captured file in wireshark and "save as" with the filters in place to a new file.

Hi ezwul!

This PC runs LinuxMint Mate 1.8.1 (qiana) which will install Wireshark 1.10.6 from the repositories,
when I click save-as I get a very limited screen where I can only select a different path / file location.

I found the answer on this page: [www.wireshark.org]

Question:

From: "Gaudineer, Kevin"
Date: Thu, 9 Jan 2014 16:43:01 +0000

Have the ‘Save Capture File’ option’s been changed or moved to another menu?

I have downloaded and installed WireShark 1.10.5 (32 bit for Windows XP)  and captured a file.
I used a display filter to only show the packets I was interested in (tcp.stream eq 0) and then tried to save the filtered display.
When I select   File -> Save As I only get the typical windows file save as dialog box the Wireshark file save as used to have
choices like displayed packets  or all captured packets   or a range of packets  All of those options are  now gone on my screen.

Answer:

From: Evan Huus
Date: Fri, 10 Jan 2014 11:07:04 -0500

Yes, the advanced options for saving only filtered packets or only
particular ranges are now under "File -> Export Specified Packets"
instead.

Evan

---

RS-Online Ormerod #263, Kossel mini with Minitronics, Prusa i3 MK2