I have released version 1.09m of my fork of RepRapFirmware at [github.com] (follow the link and press Raw to download). The recommended web interface to use with it is DuetWebControl 1.07. Here is the change list:

New features
============
The PWM frequency for the heated bed and for any heater used as a chamber heater is now 10Hz for bettercompatibility with DC-AC SSRs.

The PWM frequency for fans is now configurable using the F paramete ron the M106 command. The default is 500Hz, which gives esonable control of fans not designed for PWM. Increase it to 25000Hz when using 4-wire PWM fans.

When a Duet 0.8.5 board is configured or detected, the fan control is now automatically inverted. If you previously used M106 P0 I1 in config.g to invert it, you will need to remove that.

M579 (scale Cartesian axes) is now implemented (thanks chrishamm).

M27, M114, M119 and M573 commands can now be executed concurrently with other commands.

When DDA debugging is enabled, the debug output now includes all active extruders instead of just the first two.

M408 S0 now includes the fan speeds (for PanelDue).

M119 now reports the Z probe as well as the endstop switch states for compatibility with Marlin etc..

A tool can now be defined even if a tool with the same tool number exists already. The existing tool will be shut down and deleted.

The bed heater can now be disabled using M140 S-1 (thanks chrishamm).

The chamber heater (if present) and the endstop switch states are now reported to the web interface (thanks chrishamm).

Increased default Z prove dive height to 5mm.

Increased default PID Ki to 0.2

Bug fixes
=========
On a CoreXY machine, XY speeds were too low by a factor of sqrt(2).

On a delta machine, after running auto calibration the Z=0 height could be slightly inaccurate, depending on the difference between the X and Z endstop corrections

When using a non-intelligent modulated Z probe on a Duet 0.8.5, the modulation pin number was incorrect.

The M27 (Report SD card print status) response was inverted compared to what it should be. When in Marlin mode it now includes the "byte n/m" field that some versions of Pronterface expect.

Cold extrusion prevention did not work - an error message was generated, but the extruder was driven anyway.

M999 PERASE is now more reliable (thanks chrishamm), but still not completely reliable.

M23, M30 and M32 commands did not work when the filename parameter passed included an absolute path.

A memory leak occurred when a tool was deleted.

All moves are now completed before switching to CoreXY mode.

Polling requests from PanelDue were not replied to when a macro was being executed

M667 with no parameters returned an incorrect string

---

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'm currently very happy with the 1.09k way of handling bed PID (I'm using a 12v heated PCB ). Is there anyway we can be allowed to specify an alternate frequency for that channel? Thanks!

Edited 1 time(s). Last edit at 12/07/2015 03:57AM by n8bot.

Quote
n8bot
I'm currently very happy with the 1.09k way of handling bed PID (I'm using a 12v heated PCB ). Is there anyway we can be allowed to specify an alternate frequency for that channel? Thanks!

Not yet, however I can't think of any disadvantages to using slower PWM for the bed, which is why I haven't made it adjustable.

---

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 dc42 for your continuing work on the duet firmware.
Reading the release notes, I was wondering how to use and what is the full description of the following codes:-
M579
M573
M30
M667

I have a spreadsheet listing that was kindly supplied to me in Feb 2015 v1.10. It is now way out of date and I was wondering if you, or anybody else, had a listing that included the latest changes.

Again, thanks for the great work

---

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 see that your firmware is being names as:-
1.09m-beta3-dc42 (2015-12-06) in the software information screen of DWC

Is this correct?

---

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

No, it should be just 1.09m-dc42. I'll check it when I am in the office.

---

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

Using your firmware at the office on 2 different Ormerod printers, and both exhibit the same issues on occasion. Basically it will not allow me to do anything using the web interface, because it wants me to enter the password for the printer.
Using the default password in the configuration doesn't work, and if you examine at a lower level the web page requests page rr_connect?password=reprap and in response it gets a JSON packet of {err: 1} which web page interprets as a request for the correct password.

This can manifest in two different ways:
Sometimes the error occurs during a print where the Web page suddenly reports an AJAX error and from then on won't allow you to connect, the password dialog pops up.
Sometimes the printer has just been left alone for a while, and when I next try to connect or control it, or refresh the page, the password dialog pops up.

I love using the web interface and the your latest firmware, but this particular error is somewhat frustrating - I thought it might be specific to the printer, but when I started with the 2nd printer I realised that it can't be

Strange, the password handling hasn't changed in several firmware versions. Which version of firmware were you using previously? Do you have a M551 command in config.g to set the password?

---

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

There is definitely one of those difficult-to-diagnose bugs in the web interface and/or network code. Most times the web interface is perfect, but every now and again it will disconnect, seemingly at random, sometimes with an Ajax error reported, sometimes not. Thereafter I cannot reconnect to the printer unless I either power-cycle the printer or use a different browser to connect. I realise that in order to get to the bottom of the issue I should be doing some diagnoses at that point (network traces etc.) but it usually happens when I am wanting to get a print completed, and so I don't want to stop and spend the time to gather the required information. Nor can I find a way to reliably reproduce the issue. I suspect that it may be a network error or timeout condition that is not being handled sufficiently robustly. The fact that a different browser can connect when the other browser will not connect until a reboot of the Duet is however quite puzzling - it doesn't matter which browser I use first (Firefox or Chrome), after the fault situation that browser will not connect but the other one will. I also seem to get more disconnects happening when the Ormerod is not printing (e.g. while waiting for the bed to heat) than I do during a print.

Dave

Quote
dmould
There is definitely one of those difficult-to-diagnose bugs in the web interface and/or network code. Most times the web interface is perfect, but every now and again it will disconnect, seemingly at random, sometimes with an Ajax error reported, sometimes not. Thereafter I cannot reconnect to the printer unless I either power-cycle the printer or use a different browser to connect. I realise that in order to get to the bottom of the issue I should be doing some diagnoses at that point (network traces etc.) but it usually happens when I am wanting to get a print completed, and so I don't want to stop and spend the time to gather the required information. Nor can I find a way to reliably reproduce the issue. I suspect that it may be a network error or timeout condition that is not being handled sufficiently robustly. The fact that a different browser can connect when the other browser will not connect until a reboot of the Duet is however quite puzzling - it doesn't matter which browser I use first (Firefox or Chrome), after the fault situation that browser will not connect but the other one will. I also seem to get more disconnects happening when the Ormerod is not printing (e.g. while waiting for the bed to heat) than I do during a print.

Dave

Same as Dave. The new 1.07 web interface randomly disconnects on my laptop and pc which I've recently put Windows 10 on. I reconnect by refreshing the page but something is definitely amiss.
I'll try my mobile with a chrome app to see what that shows up.
Jon

---

Ormerod 113

Quote
appjaws1
I see that your firmware is being names as:-
1.09m-beta3-dc42 (2015-12-06) in the software information screen of DWC

Is this correct?

I've just fixed this and published a new 1.09m-dc42 binary. it is identical to the previous one except for the version string.

---

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
dmould
There is definitely one of those difficult-to-diagnose bugs in the web interface and/or network code. Most times the web interface is perfect, but every now and again it will disconnect, seemingly at random, sometimes with an Ajax error reported, sometimes not. Thereafter I cannot reconnect to the printer unless I either power-cycle the printer or use a different browser to connect. I realise that in order to get to the bottom of the issue I should be doing some diagnoses at that point (network traces etc.) but it usually happens when I am wanting to get a print completed, and so I don't want to stop and spend the time to gather the required information. Nor can I find a way to reliably reproduce the issue. I suspect that it may be a network error or timeout condition that is not being handled sufficiently robustly. The fact that a different browser can connect when the other browser will not connect until a reboot of the Duet is however quite puzzling - it doesn't matter which browser I use first (Firefox or Chrome), after the fault situation that browser will not connect but the other one will. I also seem to get more disconnects happening when the Ormerod is not printing (e.g. while waiting for the bed to heat) than I do during a print.
Dave

I observed this also with 1.09k-dc42. It is somehow annoying. Sometimes a browser cache cleanup may help, but with 1.09k it seems to be more present. I did not test a newer version. However 1.09n-ch seems to be more stable or it is related as it is another printer and therefore another Duet board. Maybe i is caused due to different network code?

---

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.

Quote
dc42
Strange, the password handling hasn't changed in several firmware versions. Which version of firmware were you using previously? Do you have a M551 command in config.g to set the password?

I'm not sure it's actually the password handling, unless err: 1 leads you to believe that?

I have indeed got the default M551 message in my config with the default password.
I have experienced this with both 1.09k-dc42 (2015-09-20) with web interface HTML: 1.06, JS: 1.06 and 1.00o-dc42 (2015-03-06) with web interface 1.03.

Quote
dmould
There is definitely one of those difficult-to-diagnose bugs in the web interface and/or network code. Most times the web interface is perfect, but every now and again it will disconnect, seemingly at random, sometimes with an Ajax error reported, sometimes not. Thereafter I cannot reconnect to the printer unless I either power-cycle the printer or use a different browser to connect. I realise that in order to get to the bottom of the issue I should be doing some diagnoses at that point (network traces etc.) but it usually happens when I am wanting to get a print completed, and so I don't want to stop and spend the time to gather the required information. Nor can I find a way to reliably reproduce the issue. I suspect that it may be a network error or timeout condition that is not being handled sufficiently robustly. The fact that a different browser can connect when the other browser will not connect until a reboot of the Duet is however quite puzzling - it doesn't matter which browser I use first (Firefox or Chrome), after the fault situation that browser will not connect but the other one will. I also seem to get more disconnects happening when the Ormerod is not printing (e.g. while waiting for the bed to heat) than I do during a print.

Dave

Did you notice the details of the Ajax error message? I have just fixed a probable bug that I believe was causing the Ajax errors during printing reported by one user. See [forums.reprap.org].

Edited 1 time(s). Last edit at 12/09/2015 04: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].

Quote
dc42

Quote
dmould
There is definitely one of those difficult-to-diagnose bugs in the web interface and/or network code. Most times the web interface is perfect, but every now and again it will disconnect, seemingly at random, sometimes with an Ajax error reported, sometimes not. Thereafter I cannot reconnect to the printer unless I either power-cycle the printer or use a different browser to connect. I realise that in order to get to the bottom of the issue I should be doing some diagnoses at that point (network traces etc.) but it usually happens when I am wanting to get a print completed, and so I don't want to stop and spend the time to gather the required information. Nor can I find a way to reliably reproduce the issue. I suspect that it may be a network error or timeout condition that is not being handled sufficiently robustly. The fact that a different browser can connect when the other browser will not connect until a reboot of the Duet is however quite puzzling - it doesn't matter which browser I use first (Firefox or Chrome), after the fault situation that browser will not connect but the other one will. I also seem to get more disconnects happening when the Ormerod is not printing (e.g. while waiting for the bed to heat) than I do during a print.

Dave

Did you notice the details of the Ajax error message? I have just fixed a probable bug that I believe was causing the Ajax errors during printing reported by one user. See [forums.reprap.org].

I'd be happy to try diagnose the problem further, but it does happen randomly, so it's difficult to reproduce.
I've got Chrome running with the developer options and the network tab open, so hopefully that would work out..

Quote
dc42
Did you notice the details of the Ajax error message? I have just fixed a probable bug that I believe was causing the Ajax errors during printing reported by one user. See [forums.reprap.org].

No - but I suspect that is a red herring as it seems very random and there is not always an Ajax error when it disconnects, just an unresponsive browser. Random disconnects have been an issue for me since the very first (RRP) firmware, and I suspect it is a network code error (possibly in a library) that has been there since the beginning. One day I'll get stuck in to some serious debug data gathering to give you something solid to work with, but it is presently nowhere near annoying enough to worry about.

Dave

Quote
dmould

Quote
dc42
Did you notice the details of the Ajax error message? I have just fixed a probable bug that I believe was causing the Ajax errors during printing reported by one user. See [forums.reprap.org].

No - but I suspect that is a red herring as it seems very random and there is not always an Ajax error when it disconnects, just an unresponsive browser. Random disconnects have been an issue for me since the very first (RRP) firmware, and I suspect it is a network code error (possibly in a library) that has been there since the beginning. One day I'll get stuck in to some serious debug data gathering to give you something solid to work with, but it is presently nowhere near annoying enough to worry about.

Dave

My printer is currently in the state where I can't connect to it. I've tried Chrome, Firefox and IE with no success.
A reboot will sort it out I'm sure, but I'm unsure that it would be a network error, considering that the Duet is sending through the whole page and responding with the {err: 1} JSON packet - surely a catastrophic network error would not be able to do that?

Edited 1 time(s). Last edit at 12/10/2015 04:31AM by VortyZA.

Sounds like I need to do a special build to provide more information on the meaning of the "err:1" response.

---

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
Sounds like I need to do a special build to provide more information on the meaning of the "err:1" response.

I had a glance at the code and it looks like all I need to do is clear the default password in the config and it would bypass that particular problem.. Might be hiding a deeper issue though.

VortyZA, please install the special firmware build at [dl.dropboxusercontent.com]. When a password mismatch occurs, it returns the received password and the expected password in the json response.

---

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
VortyZA, please install the special firmware build at [dl.dropboxusercontent.com]. When a password mismatch occurs, it returns the received password and the expected password in the json response.

I've downloaded it and will get back to you.. I thought it might be more about the IP that is stored in the list of authenticated IPs rather than the actual password itself.