New RepRapFirmware 1.09m-dc42

I am pleased to announce a new release of my fork of RepRapFirmware. You can download a binary for the Duet by following this link [github.com] and pressing the Raw button.

Apart from some code tidying up, the changes in this release are as follows (unfortunately I have not yet had time to integrate some changes from dcnewman's fork and chrishamm's fork):

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

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

With last firmware, how can we use M579 command ?

Quote
lolocaledo
With last firmware, how can we use M579 command ?

See [reprap.org].

---

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 am having issues with the cold extrusion and debugging commands working. I originally posted this in another thread but think it might do better over here...

I am trying to get my printer wired up and trying to test the extruder out. I could not get the motor to turn, but after sending the command, I couldn't turn the motor by hand so I know power is getting to it. If I use the macro to turn off the extruder motor, I can turn the motor by hand. So it seems to be getting power.

I don't have a thermistor connected and the web interface is showing an error. However, I have cold extrusion enabled, but guessing maybe the error over rides that. So I connect a resistor and get the temperature reporting around 140c. The extruder will still not work. I check and reissue the command to allow cold extrusion. Still no luck. Change resistor to get the temp over 170 and now the motor will turn.

So. For some reason, the cold extrusion doesn't seem to be working. I also tried to enable debugging but I can't seem to get that working either.

I am running 1.09m-dc42 (2015-12-08) and update to the 1.07 web files.

Did you type M302 P1 ?
I forgot to send P1 when testing my duet and checked the rules here.
-Olaf

Quote
o_lampe
Did you type M302 P1 ?
I forgot to send P1 when testing my duet and checked the rules here.
-Olaf

Yes. Sending just the M302 indicated it was enabled. After a P0, it indicated it was disabled. However, in both cases, trying to move the extruder resulted in the error message that the tool's temp was too cold.

I'll test cold extrusion prevention enable/disable in my fork when I get time.

---

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 confirm that in 1.09m you can't disable cold extrusion prevention. I am sorry about that, and I will fix it in 1.09n, which I hope to release by the end of the week. Meanwhile, if cold extrusion is important to you then you can use 1.09k or one of chrishamm's versions.

---

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
I confirm that in 1.09m you can't disable cold extrusion prevention. I am sorry about that, and I will fix it in 1.09n, which I hope to release by the end of the week. Meanwhile, if cold extrusion is important to you then you can use 1.09k or one of chrishamm's versions.

Not a problem for now. Just glad it wasn't something I was doing wrong - again. I'm using a resistor to simulate the correct temperature to allow extrusion.

I was also having issues with turning on debugging. No matter what value I passed, it always reported as being off. Is the debug output suppose to be visible in the G-Code terminal or do I need to be connected via USB to see it?

Edited 1 time(s). Last edit at 12/15/2015 08:13AM by ElmoC.

Debugging output is only sent to the USB port.

---

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

Would it consume too much memory/resources to have the RepRap Firmware announce a local name on the network?

Would be great if I could connect to my Duet as duet.local or something as opposed to the specific IP but that may take more resources than are available on an M3 platform.

Quote
WZ9V
Would it consume too much memory/resources to have the RepRap Firmware announce a local name on the network?

Would be great if I could connect to my Duet as duet.local or something as opposed to the specific IP but that may take more resources than are available on an M3 platform.

You could add the name to your host file and then refer to it by name. On windows, C:\Windows\System32\drivers\etc\hosts. *nix c:\etc\hosts.

Quote
WZ9V
Would it consume too much memory/resources to have the RepRap Firmware announce a local name on the network?

Would be great if I could connect to my Duet as duet.local or something as opposed to the specific IP but that may take more resources than are available on an M3 platform.

RRF already announces its name using the NETBIOS protocol. The name is formed from the machine name you specify in the M551 command, by stripping out spaces and other special characters. I have "M551 PKossel" in the config.g on one of my machines, and I address it as "kossel/" in the browser.

---

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

That only works with static IP. I'd prefer to let the board use DHCP but be able to address it by name.

I'll try what DC42 posted.

Quote
WZ9V
That only works with static IP. I'd prefer to let the board use DHCP but be able to address it by name.

I'll try what DC42 posted.

When I made my post, I wasn't aware that the firmware advertised itself like that. I tried it on my system and it worked perfectly.

Small files like what is generated for bed.g by the wizard fail to upload properly. Mine was 539 bytes and failed. i copied all the lines and then commented the second set out and it transferred OK once it was about 1K in size.

I had the same problem - the wizard reports that the upload has failed. However, when I checked the file on the SD card it had been updated, so it looks like the firmware/webcode isn't noting the completion of the upload correctly.

Quote
WZ9V
Small files like what is generated for bed.g by the wizard fail to upload properly. Mine was 539 bytes and failed. i copied all the lines and then commented the second set out and it transferred OK once it was about 1K in size.

This has been reported by one other user. He tried a different browser and the problem went away. Unfortunately, neither I nor chrishamm can reproduce it. However, if you also find it goes away when you change browser (e.g. between Firefox and Chrome), then if you can send Wireshark traces of successful and unsuccessful transfers of the same file, that may help us.

---

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

It appears to be specific to FireFox. When I used Chrome it went away. If a wire shark capture would be helpful I can reproduce the problem with Firefox and send one. It's very easy to reproduce with either bed.g or homedelta.g both of which are about 600 or so bytes. I know if I add comments to get them up around 1K or so that transfer in Firefox just fine.

Thanks. Please send Wireshark traces using both browsers.

---

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'll try and grab the wireshark captures for both Chrome and FireFox.

Advertising a netbios name is a very Windows WINS based solution. I was hoping it could advertise itself using mDNS which is picked up by Linux without having to install special netbios support for WINS.

I suggest you send chrishamm a PM regarding mDNS, because he has taken over support of the Ethernet support in the firmware.

---

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'll send that suggestion to him. How should I send the wireshark captures of the failed transfers to you? I plan to grab them tonight.

Chrome works for the uploads so I've just been using that for now. It appears to be FireFox specific, at least on my setup.

Quote
WZ9V
I'll send that suggestion to him. How should I send the wireshark captures of the failed transfers to you? I plan to grab them tonight.

Chrome works for the uploads so I've just been using that for now. It appears to be FireFox specific, at least on my setup.

I have replied by PM.

---

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