I've just released this at [github.com]. The only change is to increase the upload speed to 2.5Mb/min (was 1.3Mb/min in older versions). Only reprap.htm and js/reprap.js are changed since 0.74. As with 0.74, it is designed to work with firmware 0.59-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].

David,
can you remind me of the optimum way to upgrade from my old (065 I think) files?
greg

---

Ormerod #17

Greg, assuming you are running 059-dc42 firmware, then all the web files can be served from the SD card. Download the github repository I linked to as a zip. It will contain a single folder called OrmerodWebControl-master. Copy all the files and directories in that folder into the www folder on the SD card. You can omit file README.md if you want.

Edited 1 time(s). Last edit at 05/10/2014 07:36AM 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].

Thanks for the worthwhile speed improvement.

Given that most updates to the web side involve reprap.htm and reprap.js it would be quite nice to update the reprap.js from the web page as well and avoid SD card removal when it just those two.

Bob, I agree. The firmware already supports uploading other files, so the work needs to be done in the web interface. Maybe Matt will have time to do this soon, he's better at web/javascript code than I am.

---

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

Hi and thx DC42.
Tested 0.59 and 0.75 for some prints now and that's it i go web control only now.

BIG thx for the fantastic job

Thank you. I will update as soon as I can. :-) The upload speed has, from the start, been surprisingly low. What is/was the limitation depending on?

Michael, there are several things that can limit upload speed:

1. The speed at which the firmware can accept data sent by the web interface. I rewrote parts of the network code in version 058, so this is no longer the limiting factor at present.

2. The speed at which the firmware writes to the SD card. Not currently a limiting factor, but might become so if other things are speeded up.

3. The speed at which the javascript web interface code can send the data. This is what I improved in version 0.75. I can't see any easy way of increasing it further other than by increasing the transaction size; but I am not a javascript expert, so there might be ways of speeding up the javascript that I am not aware of.

4. The protocol used, which currently requires that each data packet sent to the Duet is acknowledged before another packet is sent. There is scope for improvement here, either by having the Duet respond faster, or by using a protocol that allows delayed acknowledge. In principle a standard protocol such as FTP could be used, but I think that would be a lot more work.

5. The maximum amount of data that is sent in each packet. This is currently 900 bytes, but I am considering increasing it if I do any more firmware releases

Now that RRP has started releasing firmware again (which is a good thing), I have to consider carefully whether I should spend any more time on developing the firmware. It doesn't make sense to have two separate streams of Duet firmware, and without a multi-head machine I cannot integrate and test the multi-head support that RRP has added to their master version.

---

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
Bob, I agree. The firmware already supports uploading other files, so the work needs to be done in the web interface. Maybe Matt will have time to do this soon, he's better at web/javascript code than I am.

I played around with this a bit. The sys side is easy and the current config.sys control does actually allow any gcode file into the sys folder. It passes the filename over in the M559 and then writes it to the sys folder. Just changing the name is all that is needed there. This means one can already update home files and add macros from the web interface.

The M560 for the www folder is currently hardwired to reprap.htm in the firmware. I did a quick mod to the firmware to support PFilename in M560 and added an extra button on the web side (leaving the original reprap one alone). That also worked and I could write any html to the ww folder.

The bit I haven't got working is the subfolders js and css. I was planning to use direct the files to these subfolders using the extensions as you can't get an explicit path on the web side due to security. I have tried both passing the js/ and css/ from the web based on extension and also tried doing this at the firmware end, but it ends up throwing errors when trying to open for write to the subfolders. I could still be doing something wrong but the name looks well formed so I am wondering if there is something lower in the filing system getting in the way of this.

Occasionally when I go to the 'SD Upload Drop' button and select a gcode file the printer will immediately start printing, and show the greyed out screen 'File upload Status' with the progress bar. If that's not what I'm aiming for, then I have to either reload the page to get control back or reset the printer and restart the web interface.
I'm not totally sure what could be the problem and what to test, the common thread seems to be that I've set the Bed compensation manually or using a gcode file on the SD card when this starts.

Hi VortyZA, there have been a couple of reports of this problem, although not since I released 0.59. Please check the following:

* Are you running the 0.59 release of my firmware? If you are running a 0.58 or a 0.59 beta version, please upgrade.

* Before uploading, run the command M111 S2 and look at the response in the message log, in particular the "Free file entries" value. It should normally be 10, but may be 9 if you have paused or abandoned a print. If it is close to zero, then reset the Duet. If you ever discover a way to get it to fall below 9 other than momentarily, please let me know how.

Edited 2 time(s). Last edit at 05/12/2014 04:18PM 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].

Thanks for the Hard Work David... Much appreciated...
Kim

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Quote
dc42
Hi VortyZA, there have been a couple of reports of this problem, although not since I released 0.59. Please check the following:

* Are you running the 0.59 release of my firmware? If you are running a 0.58 or a 0.59 beta version, please upgrade.

It doesn't say beta, but it does report as 0.59b.

Quote
dc42
* Before uploading, run the command M111 S2 and look at the response in the message log, in particular the "Free file entries" value. It should normally be 10, but may be 9 if you have paused or abandoned a print. If it is close to zero, then reset the Duet. If you ever discover a way to get it to fall below 9 other than momentarily, please let me know how.

I'll do so and get back to you if it happens again - thanks for the response.

If it says 0.59b then that's not one of my official releases. It might be a temporary build I put on Dropbox to fix a specific problem for someone. My current release returns this:

FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.59-dc42 ELECTRONICSuet DATE:2014-05-08

Download it from [github.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].

This has just happened to me. I have uploaded a bunch of files without issue but just went to print a new set of Matt's Z gears and it tries to print them right away. Other files with the same Slic3r settings work fine.

I have attached one of the offending files?

Is it just me or am I going mad?

Duet Firmware: 0.59-dc42
reprap.htm: 0.75
reprap.js: 0.75

Regards,

Les

---

Pointy's Things
Pointy's Blog

Hi Les,

I'm not sure whether it is the same issue that I'm seeing because I am running experimental versions of the firmware and the web interface (0.59a and 0.76). However, when I try to upload that file to SD card, the printer moves the head to the park position as if to start printing, then does nothing. The web interface is frozen. After a few seconds the Duet resets due to spin loop timeout. The software reset code 0x1002, indicating that the network layer got stuck.

I'll track it down, then I will know whether it affects 0.59 and 0.75 or not. In the meantime, please reset, reconnect, send command M111 S2 and see what the last software reset code is.

---

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 had to switch it off quick as it tried to print without any heaters on!

Strange how its just affects a couple of files though.

Regards,

Les

---

Pointy's Things
Pointy's Blog

Quote
Pointy
I had to switch it off quick as it tried to print without any heaters on!

Strange how its just affects a couple of files though.

Found the problem. Rename the file before uploading so that the filename does not contain an uppercase G. This affects all firmware versions, both mine and official RRP ones. Will fix in 0.59a.

---

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

Quote
Pointy
I had to switch it off quick as it tried to print without any heaters on!

Strange how its just affects a couple of files though.

Found the problem. Rename the file before uploading so that the filename does not contain an uppercase G. This affects all firmware versions, both mine and official RRP ones. Will fix in 0.59a.

WOW! What a bizarre thing to cause an error!

I have been using Pronterface in the meantime, which didn't have any problems, but as it happens during the 8.3 naming I used lower case anyway.

Thanks for the heads up DC.

Regards,

Les

---

Pointy's Things
Pointy's Blog

I believe the problem will occur when using Pronterface too if the 8.3 filename contains an uppercase G - but as the filename is shorter then that's less likely.

---

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

Wow! Well spotted dc42 - that sounds like a difficult bug to locate!

I have played around with this a bit more to generalise the file upload and have had some success but there is still a file upload problem. This is based on v0.76 web and 59a firmware. I basically just added filename support into the M560 command and added the subfolders js or css at the web end according to extension.



This shows the upload area where I added the www item. The reprap.htm one is actually redundant but I left that in for test purposes.

The previous config.sys is renamed as it does allow any .g file into the sys folder anyway (i.e updating home files).

Uploading htm files works fine into the www root. The problem I had with uploading into the sub folders is nothing to do with them being in sub folders but is to do with the file content.

Uploading a renamed reprap.js as reprapx.js tries to go into the js folder but the upload freezes with G code buffer errors.

However, if I rename say an htm file as a js file (e.g. reprap.htm as reprapx.js) then this uploads correctly into the js folder.

This leads me to think that the errors are triggered by the file content. The 59a firmware had some changes to deal with misinterpretation of commands during uploads but I think there must be some residual errors caused by this.

The upload currently means that the file contents pass through part of the interpretation which is always going to be problematic. It works fine for the first intended use case of uploading g code files but is struggling with being generalised.

This is on the web wish list thread.