Firmware 1.21 release candidate 2 now available
-
Hi,
Duplicate of previous line and then no movement BUG RESOLVED with 1.21RC2.Thank you.
Thank you for confirming this.
-
Hi David,
M671 change does just what I wanted, now have a 'manual bed level' macro which generates the bed plane graphic as desired and then returns the default to autoleveling with the two Z screws. Thanks!Not sure if there was any change on the rotating magnet filament sensor? Did not notice anything in the release notes. Still get measured min/max 3%-5% (-2% to 5% when I force it to skip). Not clear from the docs if the setting for minimum should be more or less than the 3%? Trying either way though I get 'extruder 0 reports too much movement' at start of print for R5:7, R1:7, R0:10. (Note I retract 15mm at end of print and then extrude 16mm away from bed at beginning of print – PETG filament trying to reduce ooze). If I try to put a negative value in for the R minimum (like the reported -2% when I am hammering it) the status report displays wrong: 'allowed movement 2147483647% to 10%' .
Also when it has paused with the 'too much movement' message M591 reports 'no calibration data' -- it would be nice if it reported the value(s) outside of the preset limits that caused it to fail?
Thanks!
Rob. -
I didn't get time to hook up the rotating magnet filament monitor and test it before releasing this RC.
-
Hi,
I think there might be a problem with the new BLTouch probe type together with multi-touch Z probing, where it does retract but not re-deploy between the multiple probings for one point.I have also opened an issue on github about this while I was waiting for my forum account: https://github.com/dc42/RepRapFirmware/issues/160
-
While I am not affected by most of the use cases that this release was designed to address, I can report that I ran two back to back 10+ hours print yesterday with no issues at all.
The web control interface and file uploads seem to be much faster and more responsive on this release, 1.21RC1 seemed quite slow.
Looking good!
-
I've just made this available at https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease/1.21RC2. See https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md for the changes and what you need to know before upgrading.
Question on the G29 fix:
Fixed problems with G29 bed probing that were introduced in 1.21RC1
On a Delta, after completing G32 calibration followed by, what appears to be, a successful G29, I've added G29 S1 into my bed.g file. It seems to work fine, and helped with a first layer issue in one area of my bed.
After I install RC2 (or later) will I need to re-do the G29, or if i'm satisfied with my current results, can I continue to use it as is?
Thanks.
John
-
You should not need to rerun G29 when you upgrade, unless you are upgrading from a really old version - the height map format changed a while back, AFAIR between 1.18 and 1.19.
-
You should not need to rerun G29 when you upgrade, unless you are upgrading from a really old version - the height map format changed a while back, AFAIR between 1.18 and 1.19.
Thanks. Since I ran that G29 with 1.21RC1, I'll consider myself in good shape.
-
In a previous post I believe you mentioned ending updates because new hardware is in progress. Did I misread the post or can I expect something new from Duet?
Thanks, Ed -
David…
Can you give details of new hardware?
-
The reason I intend to cease updating firmware for the Duet 06/085 (also RADDS and Alligator) after release 1.21 is that I am about to change RRF for the Duet WiFi/Ethernet to use a real time operating system (RTOS), and the SAM3X8E based boards don't have enough RAM to support RTOS.
-
A few issues with this release have come to light:
- The new bltouch probe support doesn't work properly if you enable the multi-tap function, because it fails to deploy the probe before the second tap
- The multi-tap function only implements the recovery delay before the first tap at each probe point, instead of before each tap
- Support for the Duet3D rotating magnet filament sensor is not working
-
I renamed the .bin file for my Ethernet board. It seems to upload but the version on DWC does not reflect the change. M115 shows 1.20. It uploaded to my 2) WIFI boards fine
-
I renamed the .bin file for my Ethernet board. It seems to upload but the version on DWC does not reflect the change. M115 shows 1.20. It uploaded to my 2) WIFI boards fine
It sounds that the upgrade failed. Are you certain that you got the name right? Use the System Editor page of DWC to check.
-
there is no Duet Ethernet build for this version…RC1 yes, not RC2
-
there is no Duet Ethernet build for this version…RC1 yes, not RC2
OK, I see what you did – you combined ethernet and wifi builds -- I renamed the Wifi bin to DuetEthernetFirmware.bin and it worked
-
DuetEthernetFirmware.bin confirmed on DWC system editor. It copied to the config file and I even tried M997 S0. When I click "yes" to update the panel Due flashes briefly but the update does not happen. M115 still shows V1.20 I thought I had installed 1.21 RC1 but that must not have taken either.
-
Try uploading the new iap4e.bin file first.
-
I tried that. now the board will not start. I removed the SDcard and copied the iap4e and the DuetEthernetFirmware.bin to the card. How do I install the .bin file using the console on the panel due? M997 is for the WIFI.
-
Not sure if this is related to new firmware or existing issue – I've uploaded a large gcode file ~100mb and now duet is stuck with it on loading for all parameters in DWC and DWC then disconnects (ps file is called Part1.gcode) -- nothing special about the name
