New firmware 1.09m-dc42 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 https://reprap.org/forum/read.php?340,593675,593675#msg-593675 Fri, 09 Oct 2026 13:18:19 -0400 Phorum 5.2.23 https://reprap.org/forum/read.php?340,593675,595416#msg-595416 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,595416#msg-595416
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.]]> VortyZA Ormerod Fri, 11 Dec 2015 05:48:12 -0500 https://reprap.org/forum/read.php?340,593675,595019#msg-595019 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,595019#msg-595019 dl.dropboxusercontent.com]. When a password mismatch occurs, it returns the received password and the expected password in the json response.]]> dc42 Ormerod Thu, 10 Dec 2015 08:42:43 -0500 https://reprap.org/forum/read.php?340,593675,594993#msg-594993 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594993#msg-594993
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 Ormerod Thu, 10 Dec 2015 07:36:07 -0500 https://reprap.org/forum/read.php?340,593675,594926#msg-594926 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594926#msg-594926 dc42 Ormerod Thu, 10 Dec 2015 05:02:27 -0500 https://reprap.org/forum/read.php?340,593675,594918#msg-594918 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594918#msg-594918
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?]]> VortyZA Ormerod Thu, 10 Dec 2015 04:27:05 -0500 https://reprap.org/forum/read.php?340,593675,594751#msg-594751 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594751#msg-594751
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]]> dmould Ormerod Wed, 09 Dec 2015 11:11:26 -0500 https://reprap.org/forum/read.php?340,593675,594700#msg-594700 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594700#msg-594700
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..]]> VortyZA Ormerod Wed, 09 Dec 2015 07:48:55 -0500 https://reprap.org/forum/read.php?340,593675,594624#msg-594624 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594624#msg-594624
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].]]> dc42 Ormerod Wed, 09 Dec 2015 04:23:42 -0500 https://reprap.org/forum/read.php?340,593675,594609#msg-594609 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594609#msg-594609
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.]]> VortyZA Ormerod Wed, 09 Dec 2015 03:07:46 -0500 https://reprap.org/forum/read.php?340,593675,594563#msg-594563 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594563#msg-594563
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?]]> Treito Ormerod Tue, 08 Dec 2015 23:10:40 -0500 https://reprap.org/forum/read.php?340,593675,594442#msg-594442 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594442#msg-594442
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.]]> dc42 Ormerod Tue, 08 Dec 2015 15:44:46 -0500 https://reprap.org/forum/read.php?340,593675,594402#msg-594402 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594402#msg-594402
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]]> Jon Steward Ormerod Tue, 08 Dec 2015 14:13:47 -0500 https://reprap.org/forum/read.php?340,593675,594243#msg-594243 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594243#msg-594243 not printing (e.g. while waiting for the bed to heat) than I do during a print.

Dave]]> dmould Ormerod Tue, 08 Dec 2015 07:11:03 -0500 https://reprap.org/forum/read.php?340,593675,594221#msg-594221 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594221#msg-594221 dc42 Ormerod Tue, 08 Dec 2015 06:29:00 -0500 https://reprap.org/forum/read.php?340,593675,594205#msg-594205 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,594205#msg-594205 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 :)]]> VortyZA Ormerod Tue, 08 Dec 2015 05:55:58 -0500 https://reprap.org/forum/read.php?340,593675,593835#msg-593835 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,593835#msg-593835 dc42 Ormerod Mon, 07 Dec 2015 06:43:46 -0500 https://reprap.org/forum/read.php?340,593675,593828#msg-593828 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,593828#msg-593828 1.09m-beta3-dc42 (2015-12-06) in the software information screen of DWC

Is this correct?]]> appjaws1 Ormerod Mon, 07 Dec 2015 06:23:47 -0500 https://reprap.org/forum/read.php?340,593675,593811#msg-593811 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,593811#msg-593811 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]]> appjaws1 Ormerod Mon, 07 Dec 2015 05:47:21 -0500 https://reprap.org/forum/read.php?340,593675,593805#msg-593805 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,593805#msg-593805
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.]]> dc42 Ormerod Mon, 07 Dec 2015 05:07:30 -0500 https://reprap.org/forum/read.php?340,593675,593789#msg-593789 Re: New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,593789#msg-593789 n8bot Ormerod Mon, 07 Dec 2015 03:57:11 -0500 https://reprap.org/forum/read.php?340,593675,593675#msg-593675 New firmware 1.09m-dc42 https://reprap.org/forum/read.php?340,593675,593675#msg-593675 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]]> dc42 Ormerod Sun, 06 Dec 2015 17:37:37 -0500