New firmware 1.21RC3 available

joestefano · 2 Mar 2018, 14:16

David, I'm running RC2 on my Ethernet board. I downloaded RC3, renamed it according to the notes and when I upload it all it does is install in the config folder. The error message is M997 S0 cant find WifiFirmware. Not sure what to do with that. It installed and updated fine on my WiFi Boards

dc42 · 2 Mar 2018, 14:53

Did you rename it to exactly DuetWiFiFirmware.bin? Use the System Editor page of DWC to check that it is there.

joestefano · 2 Mar 2018, 15:24

I'm trying to install it on my DuetEthernet board. I renamed it "DuetEthernetFirmware.bin

kazolar · 2 Mar 2018, 16:31

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

AS-3D Druck · 3 Feb 2018, 16:56

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?

kazolar · 2 Mar 2018, 17:00

@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.

adri84dj · 2 Mar 2018, 17:01

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

kazolar · 2 Mar 2018, 17:03

@adri84dj:

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

SputnikOC3d · 3 Feb 2018, 20:05

@kazolar:

@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 Druck · 3 Feb 2018, 20:14

@SputnikOC3d:

@kazolar:

@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

kraegar · 2 Mar 2018, 21:16

@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.

Skimmy · 3 Mar 2018, 10:09

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.

dc42 · 4 Mar 2018, 07:06

@Skimmy:

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.

robm · 4 Mar 2018, 10:47

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.

Markdnd · 4 Mar 2018, 11:07

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

whosrdaddy · 4 Mar 2018, 14:31

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.

dc42 · 4 Mar 2018, 15:35

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.

dc42 · 4 Mar 2018, 15:35

@robm:

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.

resam · 4 Mar 2018, 16:20

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…

dc42 · 4 Mar 2018, 17:00

@resam:

I can confirm that FTP is working again (with my usual wget command). Thanks!

Thanks for confirming this.

@resam:

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.

@resam:

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.

@resam:

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.