Ormerod embedded web server

Hi all.

I spent most of december considering what 3D printer to buy, settled on the Ormerod in early January, ordered it, waited, and built it. This has been a slow process, mainly due to me not having much spare time, but I also enjoyed the built, and did not want to rush it. Current status, I have a fully assembled Ormerod, with the official RRP firmware, and I have pronterface running both on my MacBook and on my PC running Ubuntu. On Ubuntu I also have openscad and Slic3r running. I haven't done much printing so far (only the axis compensation and a coin trap from thingiverse), so experimenting with Slic3r settings is still on my to-do list. Thanks for all the good tips and tricks posted on this forum

I think one of the next things I want to do is to update to DC42's firmware and the nice web interface by iamburny. I suppose the dependancy on github for serving some js-files is at least as good as the dependancy on reprappro.com (which have had some instability issues, although they may be solved now).

However, I would really like my printer to be self-contained, so getting rid of the need for an external web server would be really nice. I have been looking through this forum and googling around, trying to find out if anyone has made any progress on this, but so far have not found much. I am an embedded SW developer, so I would not be afraid to take a look at it, but as you can see above, my spare time is quite limited, and so far I have not even taken a peek at the firmware source code.

---

Mikkel Holm Olsen
AKA Spaceman Spiff

If you mean to make a control unit for Ormerod so it doesnt require umbilical connection to a pc (either via ethernet or usb), That is a great idea. I too have thought about it but just dont have time to do it.

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

What I meant was modifying or entirely replacing the web server in the Duet firmware, allowing it to serve the needed .js-files, thereby getting rid of the need for an Internet connection or a local web server. For me the web interface is still a good way of establising communication with the printer.

Initially, however, my post was mainly to ask if anyone started digging into this, and if so, whether they had any break-through or gave up.

---

Mikkel Holm Olsen
AKA Spaceman Spiff

I think someone has been looking into this. Check out this thread. not sure what post it is but it definately was talked about at some point.

May be you could use a Raspberry Pi as a webserver it is cheap an uses only a few watt of 5V

jan

---

XB70

Quote
XB70
May be you could use a Raspberry Pi as a webserver it is cheap an uses only a few watt of 5V

jan

Like this [octoprint.org] maybe ?

Ray

Quote
rayhicks
Like this [octoprint.org] maybe ?

I suppose that is one solution, and I might even go that route if getting a working solution on the Duet board fails.

But I must say I second the opinion expressed by Ian in a post in the Web Interface thread:
"If a reliable webserver can be implemented on the Duet, there is no need for a Raspberry Pi."

---

Mikkel Holm Olsen
AKA Spaceman Spiff

Quote
jy_oc_hx
I think someone has been looking into this. Check out this thread. not sure what post it is but it definately was talked about at some point.

I Think I have been through that thread, and there has been mention of it several times, but so far I have not seen anyone mention any actual findings regarding the Duet web server.

---

Mikkel Holm Olsen
AKA Spaceman Spiff

Hi Mikkel,
honestly I do not like an unwieldy web server in my printer.
My choice is a PC and some Ormerod USB connected printers with remote secured management (VPN).
I've seen a lot of progress since the beginning about the embedded web server, there are definitely interested..
good luck
Dario

I use the excellent iamburny web interface in local mode copled with latest useful dc42 firmware.
As local server I use xampp installed on my pc (only light web server) , so I can start the server only when I need to print.

The configuration is very simple:
- create a reprap folder into xampp/htdocs
- copy all files and folders needed github into reprap folder
- edit reprap.htm and replace all instances of the original 192.168.1.2 address with the IP of your pc
- copy reprap.htm on the SD and put in the Duet
In this way when I need to connect the printer I have only to start xampp before launch the browser: few seconds and I can use the printer leaving more resources to the duet processor.

Roberto

---

RS Ormerod #117

In principle, the IamBurny / DC42 combination would run totally stand-alone with all the files hosted on the Duet. The problem is that it is not really supporting the multiple connections that occur when the CSS and Javascript libraries are placed on the Duet. Hence the need to host the secondary files on remote or local web server.

Again, in principle, this is fixable but is made more challenging than normal as there is not a lot of RAM to play with and multiple connections needs buffers.

The problem could be worse if you want to simultaneously access from different clients. If you don't want the remote access then setting up a simple local lightweight web server is currently a good way to go as all it has to do is serve a few files.

I've been looking into this and made a start on fixing the web server. I think there is enough ram left to do it, as long as nothing else needs much more ram.

---

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

@bobtidey: The multiple simultaneous connections are just due to the browser trying to load the page faster, which works fine in the normal case (i.e. a regular web server). For an embedded system, however, I think an acceptable work-around would be to simply only accept/handle one connection at a time, so you need only one buffer. Maybe the problem is that the code is trying to handle multiple connections (although this is pure guessing on my part, as I didn't look at the code).

@dc42: Sounds really cool. But even your current firmware modifications deserve a big thanks and thumbs up.

And I think the solution of linking to the js files on github is also quite brilliant, as it allows the development of the web interface to proceed, even though some limitations of the duet firmware has been discovered. I'm just saying that down the road it would be really nice if I did not need to have another web server or internet connection to host those files, but I can certainly live with it for now.

Excellent work dc42 and iamburny.

---

Mikkel Holm Olsen
AKA Spaceman Spiff

Quote
spiff
@bobtidey: The multiple simultaneous connections are just due to the browser trying to load the page faster, which works fine in the normal case (i.e. a regular web server). For an embedded system, however, I think an acceptable work-around would be to simply only accept/handle one connection at a time, so you need only one buffer. Maybe the problem is that the code is trying to handle multiple connections (although this is pure guessing on my part, as I didn't look at the code).

No, the current firmware accepts a single connection and returns an "out of memory" error code to the client if further connections are attempted. The problem appears to me to be that Chrome seems to assume that multiple connections to the server are available. I don't think it will be a big problem supporting multiple connections, because some of the data structures appear to me to be already designed to support multiple concurrent connections. But I have a few other tasks to complete first, such as reading the z-prove and temperatures more frequently so that noise can be better averaged out, and finishing the firmware for my new z-probe board.

Edited 1 time(s). Last edit at 02/28/2014 03:37PM 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].

Quote
dc42
No, the current firmware accepts a single connection and returns an "out of memory" error code to the client if further connections are attempted. The problem appears to me to be that Chrome seems to assume that multiple connections to the server are available. I don't think it will be a big problem supporting multiple connections, because some of the data structures appear to me to be already designed to support multiple concurrent connections. But I have a few other tasks to complete first, such as reading the z-prove and temperatures more frequently so that noise can be better averaged out, and finishing the firmware for my new z-probe board.

OK, still returning an error to the client will mean it does not attempt to get the file again - which causes the problem here. What I suggested as a work-around was to not (on the TCP level) accept (that is normally the name of the socket function) the second connection, and leverage the time-out and retransmission scheme of TCP to postpone the reply until the previous one is completed. The client (be it Chrome or Firefox) tries to get the page loading faster by opening multiple connections, but in our case that overloads the web server, returning an error to the client, and no retry is done in this case.

I wonder if I can simulate my proposed solution by making an iptables rule that only allows one HTTP connection to the Ormerod at a time.

---

Mikkel Holm Olsen
AKA Spaceman Spiff

In my opinion the use of a web interface to control the Ormerod (or any other local machinery) is the wrong way to go. It results in the embedded CPU having to devote a lot of processing effort and memory resources to serving and interpreting HTTP messages. What's next? A Java engine running on the Duet taking up 99% of its processing power perhaps? The Duet should be used primarily for controlling the mechanics. Let's keep bloatware out of the Ormerod!

In my opinion the way to go is to develop a dedicated Pronterface-like application for a PC that contains all of the GUI and user interface, and which then sends and requests/receives very simple short data blocks via a dedicated TCP/IP port - pretty much the same as the data sent/received via the USB. It should be straightforward to add to the Duet firmware a completely different TCP/IP port that will act exactly the same as the present USB port. Pronterface could be similarly modified to enable it to connect to serial, USB or LAN, and it is in many respects easier to develop a good GUI for a more versatile Pronterface than to develop HTTP code to create a similar GUI for web browsers. The TCP/IP port could even use a driver on the PC that presents it as a COM port so Pronterface should work as-is with it without any modification at all - such PC drivers are readily available, it just needs a simple module added to the Duet that similarly uses a new TCP/IP port as an alternative to its existing USB link.

Another addition to the Duet LAN side would be a dedicated UDP port. Its sole function will be to give a one packet short response to all UDP broadcasts to that unique port on the local network so that a simple "discovery" tool on the PC would be able to find and list all active Duets on the LAN (preferably integrated to the Pronterface type GUI interface). Then the Duet can get its IP address via DHCP if it has not been defined in the config file, and we have a "plug and play" solution - the Duet gets its IP address automatically and the discovery tool running on a PC finds the Duet(s) and displays it/them by name so the user doesn't have to even know what an IP address is.

So the user simply plugs the Ormerod into the LAN and powers it up, and the machine will appear in a list that comes up on a Proterface-like application running on a PC. Click on the Ormerod you want to control (if there are more than one on the LAN), and Pronterface connects to it via Ethernet and can control it. Later, similar applications can be developed for Android or suchlike, and the Ormerod could be controlled from WiFi connected tablets and palmtops. No need for an Internet connection or even an Ethernet hub or router if a suitable default IP address is chosen for when there is no DHCP response.

Dave
(#106)

I'd have to disagree with this. A web server need not be bloatware and in this case I don't believe it is. Particularly as it is not a general purpose web server and is focussed on just initially serving up the files to get the web client going and then responding to simple GETs. The client is actually where a lot of the processing is taking place. The server responds to simple Gets with a pretty lightweight connection at the server to respond to the requests for data using pretty much the same logic as it would for any other dreamt up protocol.

The big plus is that the client is inherently cross platform, and is using a standardised protocol to do its job. It is tends to be much easier to maintain and enhance compared to a native client with access to a pretty rich set of libraries. The iamburny development is an excellent example of this in practice where, in short order, he got it from nothing to an interface which surpasses Pronterface in most respects. It offers the possibility of having multiple clients accessing it at once although I don't think that is fully realisable at the moment.

There are many examples of embedded systems today using web servers for their native interface even on hardware less capable than the Duet.

Quote
bobtidey
I'd have to disagree with this. A web server need not be bloatware and in this case I don't believe it is. Particularly as it is not a general purpose web server and is focussed on just initially serving up the files to get the web client going and then responding to simple GETs. The client is actually where a lot of the processing is taking place. The server responds to simple Gets with a pretty lightweight connection at the server to respond to the requests for data using pretty much the same logic as it would for any other dreamt up protocol.

The big plus is that the client is inherently cross platform, and is using a standardised protocol to do its job. It is tends to be much easier to maintain and enhance compared to a native client with access to a pretty rich set of libraries. The iamburny development is an excellent example of this in practice where, in short order, he got it from nothing to an interface which surpasses Pronterface in most respects. It offers the possibility of having multiple clients accessing it at once although I don't think that is fully realisable at the moment.

There are many examples of embedded systems today using web servers for their native interface even on hardware less capable than the Duet.

I have been reading the development progress of the Duet webserver, and IIUC it has to deliver content that requires several concurrent connections - which is why it presently requires an off-board webserver and cannot be done entirely within the Duet. Handling interconnected and from a functional POV unnecessary concurrent connections is, for an embedded CPU that has an entirely different main function, most certainly bloatware. Yes, in theory the client is cross-platform and readily available. In practice however that is not the case unless you add even more complexity to the embedded server so that it can determine and cope with different screen sizes, aspect ratios and browser behaviour and setups etc. I've come across setups that require an SSL connection for any password entry (something that is likely to become more common) - and implementing SSL on an embedded device that also has to cope with real-time events is non-trivial (I've had to do it). A simple bidirectional TCP/IP link is also a standardised protocol but does not require the added baggage (and restrictions) of HTML and HTTP on top. Making personal settings non-volatile will require the added overhead of handling cookies for a webserver based approach - a dedicated application simply creates an initialisation file or similar. I am not sure that you really want multiple clients accessing and controlling a single printer, but if you did, that's also easily possible via a simple TCP/IP data link. Iamburny is certainly doing an excellent job, but having to have external servers set up is not at all convenient and I cannot help but think that a simple Ethernet data link that would work with the present Pronterface (which could then be improved) would have been far easier. Yes, being in the profession I am well aware of devices that use (or IMO often misuse) HTTP to provide a "universal" control or monitor platform - I've had to implement such servers myself, and in many, many cases this gives rise to a huge number of problems due to the very fact that in practice it is *not* so easy to provide a server that works on all browsers and platforms, and also because every Tom, Dick and Harry can contact the device from any standard PC or tablet on the LAN, which is rarely desirable in itself and leads to heavier and heavier security measures being needed. How many people change the default password of all these devices? I know for a fact that my neighbour has not changed the default password on his TV set - and that's not because he told me!

Sure, with many things it is desirable to be able to access them from any PC because you might want to take them somewhere else or access them remotely, but a 3D printer is unlikely to be taken to a place where someone else's ad-hoc PC is used to control it, nor is there a need to access it from a hotel room on the other side of the World. You have to install many applications in order to use the device, and one more control application is not going to make it any more difficult.

Dave
(#106)

I think we are going to have to agree to differ on this. However, please use the term bloatware in its normal sense. That is normally used to derogatively describe programs which are large, cumbersome and slow due to the addition of many unnecessary features. That does not apply here and demeans the fantastic work done by both iamburny and dc42.

I would point out that the SAM3X8E processor used in the Duet is a 32-bit processor clocked at 84MHz, so it isn't exactly underpowered for this application.

---

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

Personally, since Iamburny started releasing his web interface and DC42 his firmware, I haven't even opened Pronterface.

Yes I have a local webserver running (https only) which works without issue, however I use the remote version as I instantly know that there have been updates (especially now that Burny has integrated a check).

I am able to upload a file, start it and monitor using whatever device I have to hand (So far - windows phone, android phone, tablets (not tried an ipad as yet) WiFi or LAN connected PC or laptop), all this means I am not tied to the same room or the same machine. In fact I just check on it every now and again (visually) to make sure it hasn't gone horribly wrong (perhaps I should add a webcam in the room as well )

No matter how simple the Ormerod is made to control, there will still be issues (modelling, slicing etc) to deal with and therefore a learning curve that not everyone will be comfortable with.

At this level (or price or commercial model) it is unlikely that a one size fits all will ever work and at least we can modify to our individual tastes and needs.. I recently had the opportunity to try another printer (delivered ready to go) that cost approx. 3 times the Ormerod, the print quality was at best the same, the build volume around half. The only thing I really liked was the ability to uploads stl files and set it printing. Anyone who is after a complete Plug n Play, will/should perhaps be looking at a different class of printer.

I too find the android tablet access very useful for seeing progress from any location around the house. It runs perfectly with the standard css. It might be nice to have a read-only mode to avoid any inadvertent operations.

The webcam (ip rather than usb) is a seriously good idea that that I also want to add. Of course, an optional frame for this in the web client would be perfect. If it has a microphone as well then one could also listen in the background for any unusual sound effects.

Edited 1 time(s). Last edit at 03/03/2014 02:07PM by bobtidey.

Quote
bobtidey
The webcam (ip rather than usb) is a seriously good idea that that I also want to add. Of course, an optional frame for this in the web client would be perfect. If it has a microphone as well then one could also listen in the background for any unusual sound effects.

Lol, you had to go and say it!

If the missus moans, I'm blaming you, i have just ordered a (cheaper) IP camera with audio. Hopefully should be here in a couple of days, I will just use a new tab on the browser and let you know how it goes!!!

Mike.

USB webcam is OK if there is a permanent PC next to printer. What I really meant is that by making the stream available as IP then it is accessible from anywhere you need it.

I just lobbed on a spare webcam and am streaming it with VLC and that is working fine although I need to adjust the lighting a bit. I now have a downward looking view onto the print table.



Audio not working yet so I may have to play with the streaming a bit.

Looks like thats a working idea, unfortunately I don't have a spare pc near the printer, so the IP camera is a definite winner and if I'm really lucky, there will be a way of powering it from the duet (5v @ a max of 1.5A). To be brutally honest, I paid substantially more for a webcam last year (Logitech 910).

Anyway, I think that this topic was completely hijacked - Sorry!

Mike.

Quote
bobtidey
I think we are going to have to agree to differ on this. However, please use the term bloatware in its normal sense. That is normally used to derogatively describe programs which are large, cumbersome and slow due to the addition of many unnecessary features. That does not apply here and demeans the fantastic work done by both iamburny and dc42.

I meant no disrespect whatsoever. I use the term "bloatware" for my own code when I have been forced by marketing and/or other pressures to implement something in a technically clumsy way that could have been achieved far easier by a different approach. As one example, for marketing and logistical reasons we wanted one of our products to be able to perform simple control functions via a 3rd party USB attached device. To connect to and communicate with the USB device I had to write about 500 lines of assembler code. The exact same functionality could have been achieved by implementing the external controls via the CPU's GPIO pins - in which case it would take 3 lines of code to initialise the GPIO and only a single assembler instruction to change any or all outputs or read inputs - and would not take any CPU cycles whatsoever when not operating the external lines.

Quote
dc42
I would point out that the SAM3X8E processor used in the Duet is a 32-bit processor clocked at 84MHz, so it isn't exactly underpowered for this application.

Perhaps, though I should think some of the accelleration/decelleration calculations during a series of short moves does not leave a huge amount of spare cycles, especially if it's using floating point arithmetic (does it have a FPU co-processor?) I was however thinking more about the amount of memory (RAM and ROM) needed in typical webserver implementations. One of the processors I use is a 500MHz ARM, and I was disappointed at how slow it was when I had to implement SSL - the common encryption algorithms are very CPU intensive if done in software - even though they are all written in very code-efficient assembler. A 20MHz lowly 8 bit Z80 based design that has a dedicated encryption chip on board is a lot faster!

Dave
(#106)

I managed to get the audio on the webcam sorted and that does make it more useful as one can have the tweets and z step whistles as low level 'background music' to check nothing nasty is going on.