New Ormerod Web Interface - WIP

Quote
dc42
Maybe normal web servers send multiple chunks of the page without waiting for each chunk to be acknowledged first?

I think you are right dc, the duet web server doesn't work asynchronously, I had to disable async for all ajax requests in the new interface.

Matt

---

Limited Edition Red RS Ormerod 1 #144 of 200 - RRP 1.09fw
iamburnys Ormerod Upgrades Github
Follow me on ThingiVerse My Designs

Bob, from your Ubuntu system can you please run:

tracepath -n

It should report the Path MTU.

---

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].

tracepath to the duet from Ubuntu shows a pmtu of 1500

I checked the basic Ubuntu webserver traffic to Windows Chrome and that was running at about 6MByte/s. Regular external web traffic is going at greater than 1MB/s.

These transfers are running full TCP windowing so that multiple packets are received before ACks are needed.

The captures from the Duet showed that each packet needs an ACK before the next is sent (i.e. window is very low). I think that explains the difference between Windows and Ubuntu here as there could be more delay down the Windows TCP stack. That doesn't matter if the TCP window is reasonable but causes a big slow down if an ACK is needed before the next packet is sent.

Yesterday I was getting this sync non windowed behaviour even when downloading the reprap.htm direct from the server and not from the Duet. After a reboot and flushing all the caches I'm not getting that any more. Opening the reprap.htm from the server is async and fast. There must have been some cacheing going on. Opening reprap.htm from the Duet remains sync (slow on Windows, OK on Ubuntu).

Hi, I have ,I think, a fully working omerod but it seems to be very temperamental when using the new web controller. I can print ok with pronterface but when I try to log on, from chrome,the message I get is RECV: HTTP request:GET/HTTP,1. I am running debug visible but I get no response. The web page appears but I cannot connect! The arrow next to gcode send is functional as are the headers control print status etc but no data is getting through. I have printed a number of items under web control but now nothing happens. Can you tell me which are the latest files I should be using?

cheers

davetech



RS Omerod; 191

Hi,

nice webinterface that you built Matt.

In my case when I access the Duet Web Server I have no problem doing this when on an PC connected by LAN. If I use a wireless LAN connection the server doesn't respond after some commands, esp. when I move the axes.
I also have to log on, log off and log on again to get access to the Duet web server at all.
I have tested above with v.0.60 both with remote server and local server (Raspberry Pi on LAN).

Markus

---

XBee & electronics blog: [lookmanowire.blogspot.com]

@Markus - Interesting that a wireless connection causes problems, yet wired works fine, i'll have a try with wireless here as i always use wired.

@Davetech - its is pretty important at the moment to use the most up to date version, are you using the "remote" or "local" version? the latest files are always in my Github (see signature for link) as of today the current version are as follows.

FIRMWARE_VERSION:0.57h-dc42 DATE:2014-01-31
or
FIRMWARE_VERSION:0.57g-dc42

Interface on my github

reprap.htm v0.60
reprap.js v0.60

Matt

---

Limited Edition Red RS Ormerod 1 #144 of 200 - RRP 1.09fw
iamburnys Ormerod Upgrades Github
Follow me on ThingiVerse My Designs

I think I may have found a little clue as to the fragmentation problem from Ubuntu. The captures show that the fragments to the Duet are 750 bytes or exactly half of the MTU. Buried in the tcp stack on Linux is a function called tcp_bound_to_half_wnd. I think the purpose of this function is to limit the size of outgoing packets to no more than half of the windowing size advertised by the receiver. The Duet is using a MTU of 1500 and is probably advertising a window size of 1500 as well to enforce the one packet at a time synchronous Ack behaviour. That then triggers the Linux end to send packets of 750 bytes irrespective of its MTU settings.

I am guessing the WIndows stack doesn't have this type of functionality and hence will send the MTU of 1500.

At the moment I can't see any setting on the Linux side to bypass that behaviour but I'm still looking.

Bob, I think you are right. I discovered this morning that the Duet firmware has its TCP window size set to 1500, and I built new firmware with it increased. I'm waiting for my current print to finish before I try it out.

PS - if you want, I can make it available to you now - but it will be completely untested!

Edited 1 time(s). Last edit at 02/04/2014 08:34AM 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].

The only way i can get the interface working correctly is to connect it straight to the laptop.

I haven't tried it with the printer connected to the router and using the laptop wired. ill have a go at that later to see if it works.
I can confirm that using the laptop over wireless doesn't work. it seems like the commands are send to the interface and it is waiting for a packet to be received which never happens, so the interface is frozen

Edited 1 time(s). Last edit at 02/04/2014 08:52AM by PaulHam.

I'll give it a go as soon as you like

Quote
bobtidey
I'll give it a go as soon as you like

OK, it's at [dl.dropboxusercontent.com].

---

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].

Quote
dc42
OK, it's at [dl.dropboxusercontent.com].

Tried it out. No lockup with Maxbuffer back to 1024! Major success. 2.9MByte file took 80 seconds.

I did, however, decide to check the files uploaded onto the SD card to make sure the different packet handling was keeping the data intact.

That is a bit puzzling / worrying.

I tested with 2 files; a short 180kByte file and a longer 2.9Mbyte file.

The short one was OK; the SD card had one extra blank line at the end. The long one on the SD card was missing the last 10 lines of the file (about 650 bytes) but has a blank line. Now admittedly these were all comment lines in this case but that not always the case.

I'm not sure at this moment whether this is associated with the change in packet handling but it might have opened up a possibility of the last packet getting lost maybe by the receive handling

I do have the network captures for these so I'll first look at what is going on at the network level.

Capture shows that the bits missing from the big file are sent and are all in the last packet. Reception of the packet is acknowledged and the M29 to close the file follows on about 20msec later.

So I think there is some hazard which can lead to the last packet getting lost.

Quote
bobtidey
Capture shows that the bits missing from the big file are sent and are all in the last packet. Reception of the packet is acknowledged and the M29 to close the file follows on about 20msec later.

So I think there is some hazard which can lead to the last packet getting lost.

I think this may possibly be caused by a similar bug that I recall from many years ago when I wrote my first TCP/IP implementation! Have a look at the last data packet in your capture. Does it have the FIN flag set? If so, the bug may be the same as I had, where any data in a FIN packet is ignored, even though the data count is correctly included in the ACK serial. I had incorrectly assumed from the "Red Book" TCP specs that a FIN packet would always be standalone, like a SYN packet, and never carry any data payload.

Dave
(#106)

Thanks, Bob. Can you post somewhere the file that doesn't upload properly?

---

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].

Fin not set in any of the URL Get packets carrying the Gcodes.

The link has a zip with original file (dragged onto upload) and the file as read off the SD card (has SD prefix)

GCodeFiles

Thanks Bob, I can see that the received gcode buffer is overflowing when receiving the last few lines of that file. I'll investigate.

---

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].

Bob, the problem with that file is that line 97489 is longer than 100 characters, because it has embedded '\n' character sequences (i.e. backslash followed by lower case N) where there should presumably be newlines. What program wrote it? The current firmware has a limit of 100 characters per gcode file line.

There is a minor bug in the firmware to do with recovering from that error, which I will fix.

---

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].

Thanks. I have in the meantime tried a few other files which worked OK so I was beginning to suspect something wrong with that file.

It was written by Slic3r. I have it on both Windows platform and Ubuntu. The problem file was sliced on the Ubuntu one and is a different version and is built from source as the pre-compiled one won't run any more.

So I'll stick to the Windows Slic3r for the moment.

Looking further into the Slic3r what is happening is that the Ubuntu version is adding on the ini settings at the end as comments. The Printer start_gcode is actually one line in the ini file. This gets generated properly as real GCode at the start as individual lines but the comment at the end keeps it altogether. The WIndows version isn't adding these comments at the end.

Edited 1 time(s). Last edit at 02/04/2014 12:21PM by bobtidey.

I finally found out how to improve the speed of the web interface. New firmware build (057j-dc42) at [dl.dropboxusercontent.com]. Caution: this is highly experimental, I have not done any serious prints with it yet.

---

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].

Thanks for the reply Matt

I've had a few issues which I do not understand. I'm using 57h-dc42 and remote with reprap.min.60. The system will run with Pronterface but no web control, this is with XP on a laptop with both USB and web physically connected but the web page is not working, you can ping 192.168.1.14 no problem. But if I remove the laptop, replace the network cable with a wireless unit and feed the USB from a USB hub, power only I can control the printer via an Android tablet running chrome OR my desktop computer running Windows 7 plus chrome?? Any thoughts?

cheers

davetech

davetech, if you have the laptop connected both to the Ormerod via a cable and wirelessly to your router, have you bridged the network connections?

---

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].

dc42 - Loaded 57j. Looking good. Functionality fine and the load of initial page into Windows seems faster.

Thanks, Bob! For me the page load time under Windows 7 had decreased from about 6 seconds to less than 1 second. I'm hoping to be able to serve the other files from the Duet in the near future.

---

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].

@davetech, have you tried leaving the Hub powering the Ormerod, and using a wired lan connection from the XP laptop to the router. it may well be that the laptop's USB doesnt provide enough power to drive the Duet?

Matt

---

Limited Edition Red RS Ormerod 1 #144 of 200 - RRP 1.09fw
iamburnys Ormerod Upgrades Github
Follow me on ThingiVerse My Designs

I tried using a cable first and at one of the firmware settings it did work using the web and pronter face but now it doesn't and yes I did bridge the connections. I then used the wireless device with the laptop and it would not work either because the wireless device was powered by the powered USB hub this upset the com port I was using forcing the duet to go from 7 to 9, this upset the usb connection. Removing the laptop and using the wireless device aloud me to use either my android tablet or my desktop.

cheers

davetech

Quote
dc42
Thanks, Bob! For me the page load time under Windows 7 had decreased from about 6 seconds to less than 1 second. I'm hoping to be able to serve the other files from the Duet in the near future.

I'm seeing it well under 1 second on Ubuntu but more like 3 seconds on Windows, still faster than before. I find the perceived load time to be very dependent on how the test is done. To make it repeatable I close and re-open the browser and clear the cache. Then I have a bookmark button to make the connection. If I type the link in manually then from the network I can see the browser doing prefetch of the page so that by the time you hit return most of the data is already there and the page seems to load very fast. That's a good thing, of course, but it does stop one from seeing what the underlying performance is.

Hi Matt,

When all my devices are connected and powered the duet still works via pronterface and the arduino ide so I think I have enough power. I also do not have a long enough network cable to reach between laptop and router. At the moment I also have J9 linked to get some help from the pc supply. I have not tried J10 yet as I need to make up a lead( lack of Harwin connectors). Something else you may be interested in is [www.manufactum.de] some clips to hold the glass down instead of the current devices, I have not tried them yet as the firm needs you to spend 25 euros minimum with them, just a thought.

cheers

Davetech

Hi Dave,

It looks like its another wireless lan issue then, a few others have also reported problems when connecting over wireless, not something I can fix I'm afraid.

Re: the bed clips I'm currently using clip frame clips which work great and don't interfere with the head at all see link [www.pictureframe24.com]

Matt

---

Limited Edition Red RS Ormerod 1 #144 of 200 - RRP 1.09fw
iamburnys Ormerod Upgrades Github
Follow me on ThingiVerse My Designs