New firmware 1.21RC3 available
-
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
-
I'm getting "Error: Attempt to seek on a non-open file." upon trying to print files from slic3r PE on 1.21RC3. The same files work OK on 1.20.
-
I'm getting the same error on my corexy.
M122 - https://1drv.ms/t/s!Apv79JfGbPIwg5QsmYhl9eYy6yVTZg
when I try to downgrade to 1.21 rc2 I get
M997 S0 Error: M997: Firmware binary "Duet2CombinedFirmware.bin" not found I managed to restore RC2 after hitting erase and flashing it using SAM-BA.
Working normally now, but still using wifiserver rc3, DWC rc3 -
Same, the error pops on a CoreXY machine. As for reverting to an older version… Just rename the old firmware to Duet2CombinedFirmware.bin and proceed as usual. Worked for me.
-
I tried that, it didn't work, perhaps I didn't get the filename exactly right but I copy and paste it knowing it would need to be.
-
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.
Those commands are being sent as absolute, once you move to Z-10, it can't go anywhere on the second Z-10 because it's already there. Same thing with the second issue, you are already at Z-40 and going back in the positive direction to Z-30 and Z-20, both are 10+ moves.
-
I don't know if this was fixed in RC3 or not, but I just noticed the following issue in RC2:
When setting up a z-probe with P5 (It's a BLtouch) A3 (probe each location up to 3 times) and B1 (turn off bed heater while probing), the heater gets turned off for the FIRST of multi-tap probes, but not subsequent multi-tap probes.
So, assuming a M558 of:
M558 P5 X0 Y0 Z1 H5 F100 T4000 A3 B1
and a bed.g containing the following:
G30 P0 X1.1 Y-69.2 Z-99999
G30 P1 X-50 Y65.5 Z-99999
G30 P2 X49 Y65.5 Z-99999 S3(and the manual levelling assistant configured.)
In each of the above probes, the heater is turned off for the FIRST test in each location, but the heater is turned back on (and stays on) for the SECOND probe. (My probes are apparently within 0.03 of each other, as I don't see a third probe in any location.)
-
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.
Those commands are being sent as absolute, once you move to Z-10, it can't go anywhere on the second Z-10 because it's already there. Same thing with the second issue, you are already at Z-40 and going back in the positive direction to Z-30 and Z-20, both are 10+ moves.
Yep, I realized that once I had some more coffee.
-
I think that I might have found a bug.
When doing the command
G1 X4 Y4 F200 S2;
only the X-axis movesI am using this in my homeall.g
Here is my old homeall.g with added S2 does not work
[[language]] G91 ; Relative Positioning G1 Z5 F6000 S2 ; Lower Z G1 X4 Y4 F600 S2 ; move away from the endstops G1 S1 X-305 Y-305 F3000 ; course home X or Y G1 S1 X-305 ; course home X G1 S1 Y-305 ; course home Y G1 X4 Y4 F600 S2 ; move away from the endstops G1 S1 X-10 ; fine home X G1 S1 Y-10 ; fine home Y G90 ; Absolute positioning G1 X8 Y30 F5000 S2 ; Move to first probe point T0 ; select tool M280 P3 S160 I1 ; release Z probe alarm G1 Z5 F200 S2 ; lower bed G4 P500 ; wait for the bed to lower M401 ; deploy the probe G30 ; calibrate Z-axis M402 ; Retract Probe G1 x0 y0 F5000 ; Move to 0,0 G1 Z0 F200 ; Move to Z 0 -
I'm getting the same error on my corexy.
M122 - https://1drv.ms/t/s!Apv79JfGbPIwg5QsmYhl9eYy6yVTZg
when I try to downgrade to 1.21 rc2 I get
M997 S0 Error: M997: Firmware binary "Duet2CombinedFirmware.bin" not found I managed to restore RC2 after hitting erase and flashing it using SAM-BA.
Working normally now, but still using wifiserver rc3, DWC rc3Maybe try renaming the old firmware that you are trying to downgrade to "Duet2CombinedFirmware.bin". The newer versions look for that file name, the same way you had to rename the Duet2CombinedFirmware.bin to DuetWiFiFirmware.bin when upgrading the first time.
-
When upgrading and downgrading between firmware versions in which the expected name of the firmware binary has changed, you need to take account of:
1. The binary name that the current installed firmware expects. Firmware 1.21RC3 expects Duet2CombinedFirmware.bin. Firmware 1.21RC2 on the Duet Ethernet expects DuetWiFiFirmware.bin. Firmware 1.21RC1 and earlier expect DuetWiFiFirmware.bin or DuetEthernetFirmware.bin depending on which board you have.
2. The binary name that the currently-installed version of DuetWebControl expects. DWC 1.21RC4 expects Duet2CombinedFirmware.bin. Older versions of DWC expect DuetWiFiFirmware.bin or DuetEthernetFirmware.bin depending on which board you have.
What always works is:
- upload the firmware binary you want to install;
- use the System Editor page of DWC to rename it to the name expected by the currently-installed firmware;
- send M997 to install it.
-
Okay, well that's simple enough. That was though just a minor issue, its the fact that RC3 doesn't seem to work on corexy that was the main event for me.
-
Okay, well that's simple enough. That was though just a minor issue, its the fact that RC3 doesn't seem to work on corexy that was the main event for me.
Please provide more details of why RC3 didn't work for you, along with any relevant GCode files.
-
It's working with my CoreXY OK.
(I'm chasing some print artifacts, but they exist on 1.20 as well, so I don't think it's FW related)