RepRapFirmware 2.04RC3 now available

dc42

I have just released RRF 2.04RC3 at https://github.com/dc42/RepRapFirmware/releases/tag/2.04RC3. From the whatsnew file:

Compatible files:

DuetWiFiServer 1.23
DuetWebControl 2.0.2 (recommended) or 1.22.6

Upgrade notes:

If using this release to control a laser cutter/engraver, see the notes below on changed handling of the G1 S parameter

Feature improvements/changed behaviour:

mDNS is now supported on the Duet Ethernet and Duet Maestro
In Laser mode, if sticky laser power mode is selected, the power set by the S parameter in a G1 command is remembered across G0 moves to the next G1 move
CRC checking of uploaded file data is now supported (requires DWC 2.0.2)
When an error occurs reading or writing SD card data, the number of retries is increased to 5 and the delay between retries increases with each retry
Increased minimum motor current for open load warnings from 300 to 500mA
When writing the resurrect.g file, select the active tool before calling resurrect-prologue.g. This is to allow extrusion to be done in resurrect-prologue.g.

Bug fixes:

M675 did not take workplace coordinate offsets into account
Duet WiFi/Ethernet + DueX configurations did not start up if excessive noise was present on the DueX endstop or GPIO inputs
The SHA1 has reported by M38 sometimes had one or more zero digits missing

boldnuts

Might have found a bug in this release, my BL-touch intermittently fire's off on it's own after homing, rolling back to 2.04RC2 fixe's this issue

boldnuts

@boldnuts Increasing the P value in the G31 command seems to have fixed this issue, will keep testing

Phaedrux

@boldnuts said in RepRapFirmware 2.04RC3 now available:

@boldnuts Increasing the P value in the G31 command seems to have fixed this issue, will keep testing

What was the previous P value and what was the new value?

boldnuts

Previous P value was that has worked ok for the last 2 years was 5 and the new one that now works ok is 25

boldnuts

There is sill something not working correctly as the prob stays deployed after homing and my old retract/deploy macro's don't work any more, I need to look into this.

dc42

@boldnuts said in RepRapFirmware 2.04RC3 now available:

There is sill something not working correctly as the prob stays deployed after homing and my old retract/deploy macro's don't work any more, I need to look into this.

How have you connected the BLTouch to the Duet?

boldnuts

I am using pins 1 "5 volts", pin 2 "gnd" and pin 8 "heater 3" on the expansion header and z probe header gnd and z_probe_in.
It's also intermittently deploying and retracting again, I have again rolled back to RC2 and can confirm that this issue goes away with this version.

pipersw

@boldnuts same issue with my bltouch with P25

avaradus

@dc42 Problem with overflow buffers in longer prints is still there.
Used output buffers: 24 of 24 (24 max)
And connection with printer loss and freeze.
We really need you to fix this problem, because I plan to build 2 more printers with a Duet controller. They need to work stably 24 hours 7 days a week. And when the connection is lost and there are a lot of printers, it causes inconvenience and loss of working time.
And I can’t refuse use Duet controller because it is the best in the whole world!

dc42

@avaradus said in RepRapFirmware 2.04RC3 now available:

@dc42 Problem with overflow buffers in longer prints is still there.
Used output buffers: 24 of 24 (24 max)
And connection with printer loss and freeze.

I suspect this is related to using multiple clients on different IP addresses to access the web interface. Is that what you are doing? Are the clients instances of Duet Web Control, or something else?

avaradus

@dc42 no, i have one computer and one ip address

boldnuts

@avaradus How long do you have to be printing for this issue to show up, I have been doing 3/4 day print's and not seen it?

dc42

@avaradus said in RepRapFirmware 2.04RC3 now available:

@dc42 no, i have one computer and one ip address

Do you use any plugins to upload code from slicers to the Duet over the network?

appjaws

Printed a number of items after upgrading to 2.04RC3 and have not detected any problems whatsoever.
Great job, thanks for all of the development.

Christophe76350

@boldnuts said in RepRapFirmware 2.04RC3 now available:

I am using pins 1 "5 volts", pin 2 "gnd" and pin 8 "heater 3" on the expansion header and z probe header gnd and z_probe_in.
It's also intermittently deploying and retracting again, I have again rolled back to RC2 and can confirm that this issue goes away with this version.

Same configuration, same problem for me back in 2.03 no problem.

avaradus

@dc42 i'm use gcode generated from Kisslicer 1.5 and upload it to printer with browser Google Chrome without any plugins.
Now i have 2 printers with Duet.

First printer with Duet 0.6 working stable without any bugs and problems.
RepRapFirmware for Duet version 1.19 running on Duet 0.6
Used output buffers: 2 of 32 (32 max)

Second printer with Duet wifi
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04RC3 running on Duet WiFi 1.02 or later
Used output buffers: 5 of 24 (20 max)
There memory leak and used buffers increases and increases and later printer lost connection.

I think need remember what changes have occurred with the firmware in the functions of working with buffers? if you compare versions 1.19 and 2.04 ?

avaradus

@boldnuts Somtimes it happens in one day many times! And sometime nothing happins for a week ! This is some random bug.

Adrian52

@dc42 I have still got this issue with 2.04rc3 too, using WiFi upload from dwc 2.02 /Firefox /win 10. No other computer accessing the duet. Usually lose connection after 2-4 hrs printing - print continues to completion. Can usually connect via yat, but incomplete M122 response. Resets with m999 via yat.

dc42

@Adrian52 said in RepRapFirmware 2.04RC3 now available:

@dc42 I have still got this issue with 2.04rc3 too, using WiFi upload from dwc 2.02 /Firefox /win 10. No other computer accessing the duet. Usually lose connection after 2-4 hrs printing - print continues to completion. Can usually connect via yat, but incomplete M122 response. Resets with m999 via yat.

I have a possible fix for this, which will be included in 2.04RC4. But I can't be sure it works, because I cannot reproduce the problem.