New firmware 1.21RC3 available
-
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.
-
Why can't you home the printer (or at least one of the axes) to get the extruder out of the way?
An example I just had 5 minutes ago:
A print failed, and the nozzle was right in the middle of the printed part. I aborted the print with the STOP button on the PanelDue.
Now I got a hot nozzle sitting right on top the part. I can't move the bed down because it is not homed. I can't move the carriage away, because it would drag the nozzle through a cold printed part. I cannot home Z because there is a printed part in the way.I have to use the PanelDue console to enter a G1 S2 command, or execute a macro to resolve this potentially time-critical issue.
While I do think the general idea behind this change is reasonable, I feel that the current implementation (in combination with lacking circumventions in DWC & PanelDue) is counter productive and cumbersome to work with.
-
Why can't you home the printer (or at least one of the axes) to get the extruder out of the way?
(Keep in mind that all of this is based on my own usage with a cartesian printer - a converted flashforge creator pro to be specific. I've never used a delta type printer, so I can't even imagine how different things would be.)
Often times, homing the axis that needs to be moved would be impossible with a print on the build plate. If there's a partial print on the plate, I need to move the build plate down (or the extruder up - either way, I need to increase Z) before I can get the build out of the machine. I can't home the axis because the build is in the way, and while turning off motors and manually forcing the Z axis is possible - it's also something I avoid doing (as my Z axis is a moving build plate, not a Z moving extruder.)
Sure, I could create a macro to do this, but then what is the purpose of the "jog" controls on the paneldue?
In fact, trying to think about this, I believe I can honestly say that my cartesian printer is only in a homed state when printing or leveling the build plate. In the latter case, only Z is homed and I have the motors turned off for X and Y. Obviously, while in the middle of a print, the paneldue and DWC jog controls wouldn't be used anyway.
As well, I frequently use the jog controls (in a non-homed state) for various maintenance tasks. Usually, this is only for Z (as X/Y are easy to move when the motors are off.)
From a different perspective: With this change, when can I use the paneldue/DWC controls? The answer is "almost never."
Finally, I think this change is taking something away from users instead of giving something to them. It adds an (IMO) unneeded restriction that I'm not even sure makes sense (for cartesian printers.)
Taking a WAG, it sounds like something an OEM might want in their firmware so the end-user doesn't drive an axis beyond a stop hear the steppers skipping. If that's the case, please make this an OPTION that OEM's can enable in config.g (or an option that everyone else can turn OFF in config.g) and not a requirement.
-
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...)
...
Regards
Do you have a tutorial on how to do that?
-
Finally, I think this change is taking something away from users instead of giving something to them. It adds an (IMO) unneeded restriction that I'm not even sure makes sense (for cartesian printers.)
Taking a WAG, it sounds like something an OEM might want in their firmware so the end-user doesn't drive an axis beyond a stop hear the steppers skipping. If that's the case, please make this an OPTION that OEM's can enable in config.g (or an option that everyone else can turn OFF in config.g) and not a requirement.
Yes this should be a configurable feature!
-
Kind of odd. If I power on, go to the gcode console, and send G1 Z-10 S2 it'll move as expected. If I send the same thing again, though, no movement. But if I change the Z value to something else, like G1 Z-20 S2, then it'll move as expected.
To further confuse me, now it's moving the opposite direction I should after a few more Z moves before homing.
9:44:10 AMG1 Z-20 S2
9:44:02 AMG1 Z-30 S2
9:43:53 AMG1 Z-40 S2
9:43:44 AMG1 Z-20 S2
9:43:39 AMG1 Z-20 S2The Z-30 and Z-20 both moved the bed in positive Z instead of negative.
-
Finally, I think this change is taking something away from users instead of giving something to them. It adds an (IMO) unneeded restriction that I'm not even sure makes sense (for cartesian printers.)
Taking a WAG, it sounds like something an OEM might want in their firmware so the end-user doesn't drive an axis beyond a stop hear the steppers skipping. If that's the case, please make this an OPTION that OEM's can enable in config.g (or an option that everyone else can turn OFF in config.g) and not a requirement.
Yes this should be a configurable feature!
+1
-
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.
No, it was Simplify3D
