DWC feature request

Now that my new printer is up and running pretty reliably, I have been able to play around more with the DWC. That is some really great work. Over all, I really like it. I did make a couple changes to the CSS to use a fix-pitch font for editing the config file (I think that change has been rolled into the latest - not sure) and to move the layer time graph to the bottom of the print status page. I have a webcam running and with that on, the layer graph took up the rest of the screen and I find the collected data and Estimations more useful. By moving the layer graph to the bottom, I can see these other two items with the webcam image.

One thing that would be nice, but not sure if possible, would be to add a column to the G-Code Files page that has the date/time a file was uploaded. A lot of times I may make a change to a model I am working on and generate the G-Code for it. But if I have a print running, I can't upload it (it would be great if I could). So, I have to wait and by the time I finish the print, I might have, more likely than not, forgotten if I had uploaded the new file or not (old-timer syndrome). Having the date/time of the upload would really help. I know there is some sort of time keeping going on since the estimator show the approximate time the print should finish. The Generated by column, for me, is really not of much value. I use one slicer for 99.9% of my slicing.

I've already discussed this with chrishamm. I suggested a change to the file upload protocol to pass the file timestamp when uploading the file, so that the file on the SD card would have the same time stamp as the original. There are some additional changes that would be needed to account for DST.

---

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

I also would like this. Sometimes I change only small things in the Slicer, for example the angle of the part. This especially helps if an ABS part warps. I often use FTP for uploading. Sometimes I am unsure if I already had uploaded the file or not especially if I had to do something else between the upload and print, for example answering the phone. I often have no chance to see if I uploaded the file already or not so I have to reupload it again to be sure.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

I want to say that both chrishamm and dc42 have been doing a great job with updating the Duet firmware and the DWC. I couldn't be happier with my Duet 0.8.5 and any minor things I could think of changing are likely already on the to do list. So I am by no means critizing their work.

However, this past week with the situation happening to Octoprint, I was wondering if it might be better to switch from DWC to Octoprint, assuming it was even feasible. This would allow chrishamm and dc42 to focus on firmware tweaks and improvements while utilizing a "standardized" web interface.

Again, you guys are doing a great job and this was just a random thought that popped in my head to potentially make your lives easier.

My main problem with this idea would be the fact that I would need additional hardware and a USB connection which is unnecessary with higher costs and a higher possibility for failure. Otherwise you need somebody who creates an interface for the octoprint web interface and the Duet.
The idea of a common web interface is indeed good. This could help users to switch the printer more easily.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

Sorry Treito, didn't explain myself clearly. I was thinking more along the lines of running Octoprint on the Duet itself. The idea being is that you modify a few files on the back-end so that Octoprint will run on the 32-bit chip. Entirely possible that my idea is completely infeasible.

I did just remember one improvement though, that might not be on the to-do list...filtering file names when uploading gcode to the SD card. Right now, all files are displayed and I have selected the STL once or twice by accident. It would be nice if only *.g, *.gcd, and *.gcode files were displayed.

That means that one person would have a lot to do to change the code to run on the Duet. The second problem would be the maintenance. Depending on the amount of code changes the changes have to be submitted to the Duet, too. Since the Duet uses another OS I doubt that this would be an easy task.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

Octoprint and DWC are completely different beasts.

Octoprint is a set of python programs running on a computer, including a web server. It so can integrates with others program as with Cura (a C++ program) and served it to any device, so it does need some computing power to run python and slicer.

DWC is a web application in JavaScript, which run at 100% in your browser. The Web server is in the Firmware, but as there is no server-side language, the computing resources needed to run this web server are limited.

While you can do really a lot of things in Javascript, this is not necessarily easy to develop and there will always be less efficiency than a compiled language and it is difficult to integrate with others program (namely, slicer) which shall run on your computer. If one day, someone develop a Slicer in Javascript, that may be great, but I am not aware of someone doing that and slicer performance is quite critical.

---

Pierre

- Safety [reprap.org]
- Embedded help system for Duet and RepRap Firmware [forums.reprap.org]
- Enclosed delta printers Lily [rouzeau.net] and Lily Big [rouzeau.net]
- OpenScad delta printer simulator [github.com]
- 3D printing on my site [www.rouzeau.net]