I've released firmware 0.59a-dc42 at [github.com], and web interface 0.76 at [github.com]. Please note: RepRapPro regard my firmware fork as experimental, and may not wish to support you if you use it. However, it includes some features not found in their official release (currently 0.65e), such as support for long filenames on the SD card, ability to serve all web interface files from the SD card, recovery from loss of of the USB connection when SD card printing or web printing, use of watchdog timers to guard against firmware lockup, reporting of %complete estimates when printing from SD card via the web interface, and a few other issues listed at [github.com].

Changes in the firmware since 0.59-dc52:

* Fixed bug whereby M109 and M190 commands would wait for all heaters to reach their target temperatures instead of just the heater requested. [This was already fixed in RRP 0.65].

* Fixed bug whereby it was not possible to upload a file either by the web interface or Pronterface if the filename (the requested 8.3 filename in the case of Pronterface) contained an uppercase G character. The Duet attempted to print the file instead. [Bug is present in all previous versions and in 0.65e.]

* Fixed bug that could cause % characters in comments within files uploaded via the web interface to cause the following command in the file to malfunction.

* Implemented M220 (set speed factor override percentage) and M221 (set extrude factor override percentage) commands. The configured minimum and maximum feed rates will still be honoured if these commands are used.

* When characters in unimportant messages sent to the USB port are dropped due to insufficient bandwidth, only whole lines or the trailing ends of lines are now dropped, and each truncated line is terminated by '.' and newline. This makes it easier to make sense of the output.

* Removed the 'P' parameter in the M106 command that I added in a previous version to allow the maximum PWM value to be defined. Previously, the maximum PWM value was 1.0, and I added an extra parameter so that it could be changed to 255 as assumed by slic3r and Cura. RRP have now decided that the maximum PWM value should be 255 after all, so I have brought my fork into line and removed support for the parameter I added.

Changes in the web interface since 0.75:

* All special characters in gcode commands etc. should now be handled correctly, provided firmware 0.59a-dc42 or later is used.

* Improved upload speed for large files. Previously, the upload Mb/min for large files was slower than for small files.

* Estimated end time based on filament usage is now reported earlier (when 3% of the filament is used rather than 5%).

* Fixed bug whereby the web interface could send a data block slightly larger than the available buffer space reported by the web server, resulting in client buffer overflow in the Duet.

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

Just updated to 59a and renewed the WWW interface.
Looks to be working fine here. Thanks for fixing the temp waiting bug. Only had time to test it quickly, but seems spot on. Looking forward to printing with it tomorrow.

---

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

Thanks for your hard work DC and good catch on that naming bug.

A quick question...

I am now using my PSU control and switch off the 12v 2 minutes after a print is finished. One niggle is that if I try to set the bed temperature ready for the next print and forget to send an M80, it obviously does nothing. Can I edit the reprap.js to include an M80? Something like this...

$('div#headTemperature button#setHeadTemp').on('click', function() {
        $.askElle('gcode', "M80\nG10 P0 S" + $('input#headTempInput').val() + "\nT0");

Regards,

Les

---

Pointy's Things
Pointy's Blog

David,
Can't test the new versions yet but all looks good.
Thank you for all your hard work, I just don't know where we would be without you.
Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Hi Les, I think that edit will do what you want. I think the proper solution would be to add another machine state "Standby" to the existing three (Ready, Active, Halted) that the firmware returns and the web interface understands. Clicking the state button when the state is Standby would send the M80 command.Maybe I'll do this in a future release.

---

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 dc42,
nice to see another update I've just discovered a new bug which occurs when I try to upload a specific file via the web interface (doesn't happen with every file). When I try to upload that file, the firmware hangs up and after a few seconds the watchdog kicks in, ie. the printer is reset. If I leave the web page active, the printer will start moving once the firmware is ready again. I checked the SD card, and the file being written to is exactly 0KB big. I've collected some debug info as well, but it doesn't tell me much:

Memory usage:

Program static ram used: 40052
Dynamic ram used: 43788
Recycled dynamic ram: 2176
Current stack ram used: 1272
Maximum stack ram used: 1972
Never used ram: 10316
Last reset 00:00:08 ago, cause: software
Last software reset code & available RAM: 0x1002, 10128
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000
Free file entries: 10
ok

I'll send you the g code file via PM. Of course I'm using firmware 0.59a-dc42 and web control 0.76.

Oh, and just a note, I'm really happy you're still working on your firmware branch, because some modifications are unlikely to be ever pushed to the official RRP branch for some reason (just thinking of the watchdog, flash usage and my M106 I-parameter for example). Especially the watchdog feature is great, because it gives me more confidence when leaving my printer alone - that way I don't need to worry about my printer burning off in case an undiscovered firmware bug causes my printer to hang up. Keep up the great work

Now running 65a with the Web Interface and it seems really good so far... Thanks for the hard work.
I have noticed a couple of things, and got a couple of suggestions:-
1) The % complete, seems to include the traveling time I think, but even so may be way out. It was doing the First Layer of a 400 Layer print, and said it was 1% through..

2) I tried to Delete a Gcode file from the list of files by clicking the Dust Bin. I think because of the Long Filename the Bin Icon was in one place, and the button sensing was in another... Instead of deleting it it tried to print it.
3) I'm printing a large item at the moment, and during Slic3r building the Gcode I peeked at the file. I'd set the temp for other layers to 195', and Slic3r for a small area had set the temp to 255'. I've left it alone for now, and will see how it turns out. Would it be possible to show the current HotEnd / Bed temps with the REQUESTED (i.e. Gcode requested) Temps in brackets below the current Temps. As it's clear Slic3r sets higher temps for fast areas.
4) Not sure if there's space for this.... Could the Gcode Axi Speeds be shown? If space allows with a Maximum Requested....Maybe on a new Tab Page.....
5) Extruder Retract/Feed buttons.... I wanted to retract 5mm of filament to stop dribbling initially. I hit the 5mm buton, and it Retracted, but I was expecting to set the length and then the Feed or Retract....
Maybe have the two Buttons both inactive until they are pressed.
All of the above are just Polishing the Web Interface thou..... As it's pretty good now.... Thank You...

---

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

Hi zpl, thanks for sending that file. However, it uploaded perfectly for me, in 1min 17sec.

The error sounds rather like one I experienced using 0.59/0.75. I had the same reset and the same 0x1002 software reset code. So please check on the status page that you really are using both the new firmware and the new web interface. It should look like this:



In particular, check the reprap.js version. Note that if you didn't close your old browser window and open a new one after updating the SD card, you will still be using the old web interface.

---

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

PS An item for the wish list.....
When it's finished printing, could it record in a file the time taken to print, filament used, and maybe the firmware used? Maybe it could that file the next time the print is done to give a % completed and estimated time...

---

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

Hi Kim,

I presume you mean 59a-dc42 not 65a. On your numbered points & suggestions:

1. The % complete shown is based on filament consumption if the total filament needed is available, or number of layers completed as a proportion of object height if not. The filament consumption is based on the value shown in the "Extruder" box, less the value that was in that box when the print started, divided by the total filament required as found from the comment at the end of the file. There is also some adjustment to allow for zero-reset if e.g. G92 E0 is used, and for temporary retraction. It is rounded down to the nearest 1%. So if your print used a lot of filament in the lower layers and much less in the upper layers, it is entirely possible that more than 1% of the total filament was consumed in the first layer of a 400-layer print. I'm doing it this way because I find that the filament consumed is the most reliable predictor of end-time, although I know the prediction can be further improved (e.g. by discounting the first layer once data for a few other layers is available).

2. When you hover over the dustbin icon next to a filename, it should turn red will be deleted if clicked. If you hover over any other part of the filename, it should turn grey and will be printed of clicked. This is working for me. Let me know if you manage to get a situation in which either it doesn't turn red when over the dustbin, or does turn red but prints when clicked. It probably depends on the exact length of the filename.

3. That sounds like a good idea to me. It will need firmware changes as well as web interface changes, but should not be difficult to do. Maybe it could set the temperatures in the boxes to the right of the drop-down list to the requested temperatures when SD printing, and grey them out. They are disabled from user input when SD printing anyway.

4. Do you mean display the current speeds, or the maximum configured? The current speed are often changing very fast, and the web interface only updates about once a second, so I'm not sure whether displaying them would be worthwhile.

5. I agree this is confusing. I'll try to work out a new layout in which there are Extrude and Retract buttons that when pressed do the actual operation. Also I want to add a command to feed/retract about 400mm at high speed, for use when changing filament.

---

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

Kim, David
I found that Firefox never detected the bin, so now use Chrome for my Ormerod and FF for everything else
Greg

---

Ormerod #17

Huh, that's really weird. I've just checked the versions once more and they are correct:



Then I tried to upload that file again and got the same behaviour, the firmware hung up, restarted and reported the same error code. Here's an excerpt from my message log:

16:20:29 T:19.2 B:18.8
16:20:28 M503
; RepRapPro Ormerod
; Standard configuration G Codes
M550 POrmerod; Set the machine's name
M551 Preprap; Set the password
M552 P192.168.1.100; Set the IP address
M553 P255.255.255.0; Set netmask
M554 P192.168.1.254; Set the gateway
M555 P2; Emulate Marlin USB output
M92 E429; Set extruder steps/mm
G21 ; Work in mm
G90 ; Absolute positioning
M83 ; Extrusions relative
M558 P0 ; Enable microswitch probing
M203 X12000 Y12000 Z200 E6000 ; Set max feedrates - divide by 60 for mm/s
M201 X1000 Y1000 Z10 E1000 ; Set accelerations
M906 X1000 Y1000 Z800 E1000 ; Set motor currents
M305 P1 H28.1 L-69.3 ; Set hot end PID
T0 ; Select extruder 0
M106 P255 I1 S89 ; set fan PWM values to 35%
M556 S77 X0.0 Y0.4 Z0.9 ; orthogonal axis
M111 S2 ; debug
16:20:27 M115
FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.59a-dc42 ELECTRONICSuet DATE:2014-05-14
16:20:26 Program static ram used: 40052 Dynamic ram used: 43764 Recycled dynamic ram: 2200 Current stack ram used: 1288 Maximum stack ram used: 1828 Never used ram: 10460 Last reset 00:00:01 ago, cause: software Last software reset code & available RAM: 0x1002, 10128 Error status: 0 Bed probe heights: 0.000 0.000 0.000 0.000 Free file entries: 9 
16:20:05 Page Load Complete

I'll remove the P parameter from M106 next time I edit my config file, but I really can't imagine it has to do with the bug I am experiencing. Because this issue doesn't seem to happen when you upload my g-code file, I'll try to debug it myself this evening - and hopefully submit a pull request once I've figured out what's causing this

Also, I'm thinking of replacing the "Z probe" cell in the web interface with "Fan RPM", because I'm using a 4-pin PWM fan and a microswitch for Z-probing anyway. Can I register an additional interrupt for this purpose (would be called at a max frequency of 28kHz AFAIK) or would this somehow interfere with the stepping logic? How would you implement this?

KimBrown: About your second point - I had the same issue when using Firefox, try it with Chrome and you should be able to delete files. Firefox ignored the trash bin icon for some reason last time I used it.

Hi David, yes I meant 59a...OOps!
1) Yes that could be it, because I have a 10mm brim set for the print.
2) ok I'll try that after the print...
3)
4) I was meaning the Max speed limits set with the idea people might be able to see if they could up anything.
5) Now that would be great....

Only real niggle at the moment. The laptop crashed doing something else so had to be restarted. After starting Firefox, the printer hickupped when connecting (no problem there), then carried on printing ok after that, but all the print data, estimated time, etc was all gone and not being updated any more. Maybe if it updated the Web page on the SD card instead of doing the calcs on the Browser page it might be better. The only data still showing was the finished item size.

---

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

zpl, I'm wondering whether the amount of overhead in the html message depends on browser or operating system configuration, so that it might be higher for you than for me. Can you do a Wireshark trace of the traffic when you attempt to upload? I'm interested in the max size of html packets sent to the Duet, and the contents of the largest packets - especially the ones sent just before the Duet stops responding.

At the top of Webserver.h are some constants:

const unsigned int postLength = 1400;			// max amount of POST data we can accept
const unsigned int webInputLength = 1400;		// max size of web interface requests and related stuff
const unsigned int gcodeBufLength = 2048;		// size of our gcode ring buffer, ideally a power of 2
const unsigned int minReportedFreeBuf = 100;	// the minimum free buffer we report if not zero
const unsigned int maxReportedFreeBuf = 1024;	// the max we own up to having free, to avoid overlong messages
const unsigned int jsopnReplyLength = 1200;		// size of buffer used to hold JSON reply

I suspect that either increasing webInputLength or decreasing maxReportedFreeBuf by a small amount will fix the problem.

Edited 2 time(s). Last edit at 05/15/2014 11:24AM 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].

dc42, I tried to upload that file a few minutes ago on Linux (because I had Wireshark installed there) and it worked perfectly, just as you reported. Then I rebooted and tried the same thing on Windows 8.1 and the firmware crashed. Here's the Wireshark dump from my Windows installation: [www.dropbox.com]

If there's anything else I can do, just let me know. Thanks for looking!

Thanks, it does indeed look like the HTTP header in that capture is longer than on my Windows 7 system. As you are equipped to recompile the firmware, please try increasing both postLength and webInputLength to 1500 (see my previous reply). If that works for you, I will make that change in my next build.

Edited 1 time(s). Last edit at 05/15/2014 02:08PM 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 your suggestions, but this doesn't seem to help. I increased both values to 1500 for my first try, then to 1600, but both times the firmware hung up as before. I'm going to add some debug code and see if I can discover something else, either way I'll let you know if I find anything.

Zpl, I think there may be a problem with the LWIP MSS size as well, in which case increasing those values is not sufficient. The LWIP MSS size is already optimised for Windows, so try reducing maxReportedFreeBuf instead (and revert the others to 1400).

Edited 3 time(s). Last edit at 05/15/2014 05:23PM 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].

Wow - how did you figure that out without even being able to reproduce this problem? I've spent the past few hours looking through the webserver source code, and I'm not sure if I would have made that connection at all. Well, at least I've learned a little bit more about the Duet's firmware

Decreasing maxReportedFreeBuf along with increasing the other two consts has indeed fixed this issue for me, so these are the values I can confirm to be working:

const unsigned int postLength = 1536;			// max amount of POST data we can accept
const unsigned int webInputLength = 1536;		// max size of web interface requests and related stuff
const unsigned int gcodeBufLength = 2048;		// size of our gcode ring buffer, ideally a power of 2
const unsigned int minReportedFreeBuf = 100;	// the minimum free buffer we report if not zero
const unsigned int maxReportedFreeBuf = 900;	// the max we own up to having free, to avoid overlong messages
const unsigned int jsopnReplyLength = 1200;		// size of buffer used to hold JSON reply

Huge thanks, dc42!

[edit]Decreasing maxReportedFreeBuf appears to be sufficient, no need to change any of the other values[/edit]

Edited 1 time(s). Last edit at 05/15/2014 05:50PM by zombiepantslol.

I tried to delete a file Via Firefox, but the Dusty Bins refused to turn Red here.... (Windoze 8.1)...
Not a big deal, but passing it on..

---

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

I thought that the interface was designed to run in Chrome and that running it in any other browser would be likely to cause problems.

Is this not the case?

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

I must admit I don't like Chrome... Personal Preferance.... The only bit that doesn't work in Firefox is the Dusty Bins.... So no big deal.

---

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
zombiepantslol
[edit]Decreasing maxReportedFreeBuf appears to be sufficient, no need to change any of the other values[/edit]

Thanks zpl, I'll do a firmware minor update with that value reduced.

---

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

Where do you prefer to get bug reports? Whatever random forum thread happens to be active, a separate "bug reporting" thread, github, email, private message? One complication is that the FW and web UI live in different repos, and where a certain issue might lie in some cases is far from obvious to most of us (I guess everyone but dc42 and iamburny... )

I just re-stumbled upon a bug I remember having a few weeks back (but paying no notice to), regarding the extruder controls in the web UI. It was simple enough to fix that I could just make a patch and pull request myself, but even then I'm not sure if it should go to dc42's or iamburny's repo, or maybe even both.

I am sorry to say I still seem to be having issues with uploading files and them trying to print straight away. The good news I think, is that it still seems to be a filename issue. This time the file was called 'Z Nut Trap'. I simply renamed it to all lower case it it uploaded fine.

Regards,

Les

---

Pointy's Things
Pointy's Blog

Quote
KimBrown
I tried to delete a file Via Firefox, but the Dusty Bins refused to turn Red here.... (Windoze 8.1)...
Not a big deal, but passing it on..

I think I found the reason at [forum.jquery.com]. I'm currently rewriting it to use a styled div instead of a button.

---

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
Pointy
I am sorry to say I still seem to be having issues with uploading files and them trying to print straight away. The good news I think, is that it still seems to be a filename issue. This time the file was called 'Z Nut Trap'. I simply renamed it to all lower case it it uploaded fine.

Regards,

Les

I'll see if I can reproduce that. Was it .g or .gcode? (or something else)

---

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 am sorry to say I still seem to be having issues with uploading files and them trying to print straight away. The good news I think, is that it still seems to be a filename issue. This time the file was called 'Z Nut Trap'. I simply renamed it to all lower case it it uploaded fine.

Regards,

Les

I'll see if I can reproduce that. Was it .g or .gcode? (or something else)

.gcode

When I tried to upload it, no progress window came up, I looked at the ethernet lights on the Duet and they both went out, as if it had reset. Then the axis started moving, so I turned it off. I turned it back on again with the web interface still open and the axis just started moving again. So finally I turned off again and closed the web page, renamed to lower case and repeated the upload and it worked fine.

Regards,

Les

---

Pointy's Things
Pointy's Blog

Another possible bug...

The setbed button doesn't seem to work from the control tab.

Regards,

Les

---

Pointy's Things
Pointy's Blog

Confirming the setbed button doesn't work from the web interface

---

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