New firmware 1.21RC3 available
-
short feedback:
I was not able to install the combined-firmware file conveniently. I needed to rename it to "…WiFiFirmware" to get it to install automatically. Upgraded from RC2 to RC3.
otherwise, everything works like expected. -
short feedback:
I was not able to install the combined-firmware file conveniently. I needed to rename it to "…WiFiFirmware" to get it to install automatically.This is mentioned in the upgrade notes.
-
short feedback:
I read the instructions, everything is brilliant.
Works a treat.
DuetWifi is still the best thing since sliced bread
Second firmware version upgrade for me, second time I've got a whole load of new features that take it miles beyond what I happily paid for originally.
Thank you David, stellar job as always. -
Apologies for asking this, especially since the release notes are perfectly clear, but my brain is refusing to accept the obvious this morning…
I'd just like to confirm that the new "home before move" restrictions on G0 and G1 only relate to Cartesian and CoreXY printers and do not apply to Delta printers and so no modification is needed to homedelta.g after installing 1.21RC3
-
David, is there a way to disable the G0/G1 restrictions in RC3?
Sometimes I want to move Z out of the way before it is homed. -
I'd just like to confirm that the new "home before move" restrictions on G0 and G1 only relate to Cartesian and CoreXY printers and do not apply to Delta printers and so no modification is needed to homedelta.g after installing 1.21RC3
Delta printers and SCARA printers have always had this restriction, so no changes needed.
David, is there a way to disable the G0/G1 restrictions in RC3?
Sometimes I want to move Z out of the way before it is homed.There isn't a way to disable the restriction, however you can easily set up a macro that does G91 G1 S2 Znnn G90 for that purpose.
-
short feedback:
I read the instructions, everything is brilliant.
Works a treat.
DuetWifi is still the best thing since sliced bread
Second firmware version upgrade for me, second time I've got a whole load of new features that take it miles beyond what I happily paid for originally.
Thank you David, stellar job as always.Thank you! It's nice to see our work appreciated.
-
I can confirm that FTP is working again (with my usual wget command). Thanks!
About the "CoreXY: normal movement commands are no longer permitted":
This is very "uncommon" and breaks a few workflows. For example, I used to move my Z via the PanelDues "Move" buttons after power-up to remove a printed part or whatever, or to clean the nozzle, etc…
This currently completely breaks the move functionality of the PanelDue.
A few ideas: maybe add a "are you sure?" checkbox or something to enable unhomed moves on the Paneldues screen.
Or a new "allow unhomed moves" M-Code, similar to "M302: Allow cold extrudes".The release notes state "and the homing macro will be terminated." - which seems to be wrong or faulty. Invalid moves simply don't get executed, but the homing script continues. This could lead to crashes!
A related question, which confused me while testing homing changes: if homeall.g does NOT contain any Z-homing, does RRF automatically call homez.g after homeall.g is done?
My current homeall.g does not contain a Z-homing section, yet when I press the "Home All" buttons in DWC/PanelDue, XYZ get homed. I couldn't find anything about this in the wiki.M39 reports for my SD card: [c]SD card in slot 0: capacity 4.03Gb, free space 4.02Gb, speed 20.00MBytes/sec, cluster size 4kb[/c]. You mentioned that a cluster size of 32kB would be better for large gcode files. Would you mind sharing a suitable mkfs/formatting command? I tried a few things, but either the Duet wouldn't boot or the cluster size would still be 4kB…
-
I can confirm that FTP is working again (with my usual wget command). Thanks!
Thanks for confirming this.
The release notes state "and the homing macro will be terminated." - which seems to be wrong or faulty. Invalid moves simply don't get executed, but the homing script continues. This could lead to crashes!
Perhaps my explanation wasn't clear. If you attempt to do an unallowed move in a homing file or other macro, the rest of that file is not executed.
A related question, which confused me while testing homing changes: if homeall.g does NOT contain any Z-homing, does RRF automatically call homez.g after homeall.g is done?
My current homeall.g does not contain a Z-homing section, yet when I press the "Home All" buttons in DWC/PanelDue, XYZ get homed. I couldn't find anything about this in the wiki.Yes, that's a side-effect of a change I made a couple of versions ago, to make homing more flexible.
M39 reports for my SD card: [c]SD card in slot 0: capacity 4.03Gb, free space 4.02Gb, speed 20.00MBytes/sec, cluster size 4kb[/c]. You mentioned that a cluster size of 32kB would be better for large gcode files. Would you mind sharing a suitable mkfs/formatting command? I tried a few things, but either the Duet wouldn't boot or the cluster size would still be 4kB…
4kb does seem rather low. I'll see if we can change that. When I try to format a 2Gb SD card under Windows 10 by right-clicking on the drive and selecting Format, it offers me 32Kb and 64Kb.
-
I can confirm that FTP is working again (with my usual wget command). Thanks!
Can you please share the command you're using? I had issues (reported in an early comment) using FTP and I would like to test it
Regards
-
Can you please share the command you're using? I had issues (reported in an early comment) using FTP and I would like to test it
I use wget to download the sys folder into my current working directory: [c]wget -r -nH ftp://voron@10.0.0.42/sys[/c]
This is a "poor mans backup" - I can copy all important config files to my computer without going to the printer.Perhaps my explanation wasn't clear. If you attempt to do an unallowed move in a homing file or other macro, the rest of that file is not executed.
Then I have to report this as a bug. Because my homing script starts with [c]G1 Z3 F100[/c], and then does XY homing. The XY homing does work, and moves my carriage around as expected. If I understand you correctly, my homing script should fail and NO movement at all should be executed. Bug or are we talking about different things?
Yes, that's a side-effect of a change I made a couple of versions ago, to make homing more flexible.
Well, I started with 1.19 when I got my Duet in September - my homing works like this since the very beginning. Maybe you could mention this in the wiki. The release notes also don't mention it.
-
I'd just like to confirm that the new "home before move" restrictions on G0 and G1 only relate to Cartesian and CoreXY printers and do not apply to Delta printers and so no modification is needed to homedelta.g after installing 1.21RC3
Delta printers and SCARA printers have always had this restriction, so no changes needed.
David, is there a way to disable the G0/G1 restrictions in RC3?
Sometimes I want to move Z out of the way before it is homed.There isn't a way to disable the restriction, however you can easily set up a macro that does G91 G1 S2 Znnn G90 for that purpose.
yes I know but it is a bit of PITA, the jog buttons no longer work, is there a way to modify the jog buttons to include s2 command?
-
Can you please share the command you're using? I had issues (reported in an early comment) using FTP and I would like to test it
I use wget to download the sys folder into my current working directory: [c]wget -r -nH ftp://voron@10.0.0.42/sys[/c]
This is a "poor mans backup" - I can copy all important config files to my computer without going to the printer.Thanks! Interestingly, wget worked perfectly, Filezilla does not… It would do the trick though... (I'm downloading the config from the printer and uploading it to a git repository to track my config changes...)
Perhaps my explanation wasn't clear. If you attempt to do an unallowed move in a homing file or other macro, the rest of that file is not executed.
Then I have to report this as a bug. Because my homing script starts with [c]G1 Z3 F100[/c], and then does XY homing. The XY homing does work, and moves my carriage around as expected. If I understand you correctly, my homing script should fail and NO movement at all should be executed. Bug or are we talking about different things?
I have the same behaviour… My X homing tries to move Z up, and as Z is not homed, it fails (shows "no axis homed error"), but keeps on with the X homing (witch caused a crash with the bulldog clips a couple of times due to the fact that the Z movement wasn't executed to avoid the clip).
Regards
-
Thanks, that sounds as though it is not cancelling the homing macro as was intended.
-
I just wanted to add my "vote" to those requesting that G1 moves from PanelDue (and perhaps DWC) automatically include the S2 parameter. I often don't have a computer (or other web browser) even booted up when using my printer (thanks to PanelDue, this is possible.) However, having to manually use the paneldue console to "G1 Z50 S2" or something similar to get the extruder out of the way when it's not homed is a pain.
(I can't report any issues with this RC, as this specific issue is causing me to skip it.)
-
Why can't you home the printer (or at least one of the axes) to get the extruder out of the way?
-
Has current layer been removed from DWC in 1.21RC3?
I can’t see it anywhere just a very inaccurate completion percentage where it used to be.
(It claims I am 57.5% of the way through but the print has only 2mm to go of a 30mm print and is, in reality, at least 90% complete)
-
The graph shows you speed per layer. The right of the x axis is your layer.
-
Not as user friendly as the old “Layer x of y” but hopefully I’ll get used to it.
Having said that can I put in a vote for the the old layer information format to be brought back, if only as an option.
It was, after all, the only thing on that line that was accurate and definitely something I used on a regular basis.
-
Has current layer been removed from DWC in 1.21RC3?
I can’t see it anywhere just a very inaccurate completion percentage where it used to be.
(It claims I am 57.5% of the way through but the print has only 2mm to go of a 30mm print and is, in reality, at least 90% complete)
Was the GCode file sliced by Cura? There is an issue with displaying the current layer when printing files generated by Cura.
