New firmware 1.21RC3 available
-
I'm trying to install it on my DuetEthernet board. I renamed it "DuetEthernetFirmware.bin
-
I had to do 2 step install process which doesn't seem right I copied DuetEthernetFirmware.bin – it said that it's going to install it, then erored out saying it's missing DuetWifiFirmware.bin -- I copied that, but it didn't do anything, so I copied DuetEthernetFirmware.bin again, and that it worked.
Not sure how P9 BL touch is not supposed to work, but for me after switching to P9 -- now the 2nd probe is kinda wonky, it probes then deploys the probe again, but the bed hasn't moved away yet, so the probe hits the bed -- P5 didn't have that as pronounced, it would happen occasionally, but most of the time the bed would have moved down so that the probe would deploy freely
This is my config section for the probe
M558 P9 X0 Y0 Z0 H5 F100 T5000 A10 S0.03
G31 X-30 Y-30 Z1.85 P25 -
The new RC3 Firmware works but i don't like this:
On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated.
Is it possible to remove this?
Cause if i printed before a tiny Object and i turn the Printer off and start it the next day it cause a Problem because the BLTouch is too close to the Bed to level the Z Axis.
Ouh and is it possible to home Z with the multi touch function?
-
@AS-3D:
The new RC3 Firmware works but i don't like this:
On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated.
Is it possible to remove this?
Cause if i printed before a tiny Object and i turn the Printer off and start it the next day it cause a Problem because the BLTouch is to close to the Bed to level the Z Axis.I don't like this restriction either – I don't particularly see the point. Maybe you can add a gcode command which disables this enforcement for those of us who really don't need this.
I have 4 hot ends, 7 Axes -- I ran into this issue this morning while starting a print -- don't see why this was added.
-
I have RC2 installed on Duet Ethernet. I rename Duet2CombinedFirmware.bin by DuetWiFiFirmware.bin and upload the file.
There is no version change and also the file DuetWiFiFirmware.bin has been placed only inside System Editor.
What do I have to do to update this RC3?
regards
-
I have RC2 installed on Duet Ethernet. I rename Duet2CombinedFirmware.bin by DuetWiFiFirmware.bin and upload the file.
There is no version change and also the file DuetWiFiFirmware.bin has been placed only inside System Editor.
What do I have to do to update this RC3?
regards
see my steps – it's rather clunky -- I uploaded it twice under 2 names DuetWiFiFirmware.bin first then DuetEthernetFirmware.bin
-
@AS-3D:
The new RC3 Firmware works but i don't like this:
On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated.
Is it possible to remove this?
Cause if i printed before a tiny Object and i turn the Printer off and start it the next day it cause a Problem because the BLTouch is to close to the Bed to level the Z Axis.I don't like this restriction either – I don't particularly see the point. Maybe you can add a gcode command which disables this enforcement for those of us who really don't need this.
I have 4 hot ends, 7 Axes -- I ran into this issue this morning while starting a print -- don't see why this was added.
I wasnt fond of it but I went in and added the S2 parameter to all my HomeX/Y/Z/All.g files on all the Z moves and it works for me … again. [ as per the docs/instructions ]
I kinda feel like this "feature' should be enabled as it is now implemented by "default" but users should have the ability to disable and do damage at their own risk as they see fit
My home all - does the x / y first and raises Z … a little ... then does z
-
@AS-3D:
The new RC3 Firmware works but i don't like this:
On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated.
Is it possible to remove this?
Cause if i printed before a tiny Object and i turn the Printer off and start it the next day it cause a Problem because the BLTouch is to close to the Bed to level the Z Axis.I don't like this restriction either – I don't particularly see the point. Maybe you can add a gcode command which disables this enforcement for those of us who really don't need this.
I have 4 hot ends, 7 Axes -- I ran into this issue this morning while starting a print -- don't see why this was added.
I wasnt fond of it but I went in and added the S2 parameter to all my HomeX/Y/Z/All.g files on all the Z moves and it works for me … again. [ as per the docs/instructions ]
I kinda feel like this "feature' should be enabled as it is now implemented by "default" but users should have the ability to disable and do damage at their own risk as they see fit
My home all - does the x / y first and raises Z … a little ... then does z
Here can you see what my Printer does.
https://www.duet3d.com/forum/thread.php?pid=40824#p40824 -
@AS-3D:
The new RC3 Firmware works but i don't like this:
On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated.
Is it possible to remove this?
Cause if i printed before a tiny Object and i turn the Printer off and start it the next day it cause a Problem because the BLTouch is too close to the Bed to level the Z Axis.Ouh and is it possible to home Z with the multi touch function?
I've hit the same thing with the bltouch a couple times already. I used to just bounced it down 10mm and then reset it. now my reset bltouch macro has a jog down in Z with the S2 added, so I can actually reset the bltouch.
-
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.
