New firmware 1.21RC3 available
-
That guide is the right one for this situation
-
Any ideas why I got the M997 error at the onset ? Did i need to be running a more recent firmware version than 1.20 ?
-
Also see:
https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_BLTouch
I have linked a helpful tutorial for BL Touch by BeTrue3d.dk
Thank you …
Now i get ... Error: M997: Firmware binary "DuetWiFiFirmware.bin" is not valid for this electronics ????
That normally means you downloaded the html page describing the firmware file, instead of the firmware file.
-
Also see:
https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_BLTouch
I have linked a helpful tutorial for BL Touch by BeTrue3d.dk
Thank you …
Now i get ... Error: M997: Firmware binary "DuetWiFiFirmware.bin" is not valid for this electronics ????
That normally means you downloaded the html page describing the firmware file, instead of the firmware file.
well valuable lesson learned there … compare bytes and drill down into the github into the page where the actual files reside ... so ive followed the guide- run out and got a micro sd card reader - and moved the files and commented out the line in config .g ...
Issuing M997 S0 and M997 S1 ...
M115 gives me ...
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 1.21RC3 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2018-02-28 build 4<lf>ok <lf>Im really not clear by looking at this whether the Wifi Server firmware part is the right version?
M122 gives me :
=== Diagnostics ===
<lf>Used output buffers: 1 of 32 (9 max)
<lf>=== Platform ===
<lf>RepRapFirmware for Duet 2 WiFi/Ethernet version 1.21RC3 running on Duet WiFi 1.02 or later
<lf>Board ID: 08DGM-9568A-F23SD-6JTDD-3SJ6R-9ARZH
<lf>Static ram used: 16144<lf>Dynamic ram used: 100384
<lf>Recycled dynamic ram: 2256<lf>Stack ram used: 3568 current, 4528 maximum<
LF>Never used ram: 7760<lf>Last reset 00:14:41 ago, cause: power up
<lf>Last software reset at 2018-02-24 09:30, reason: User, spinning module GCodes, available RAM 11896 bytes (slot 3)
<lf>Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
<lf>Error status: 0<lf>Free file entries: 10<lf>SD card 0 detected, interface speed: 20.0MBytes/sec<lf>SD card longest block write time: 0.0ms<lf>MCU temperature: min 37.6, current 37.8, max 38.1<lf>Supply voltage: min 0.5, current 0.6, max 0.6, under voltage events: 0, over voltage events: 0<lf>Driver 0: ok, SG min/max not available<lf>Driver 1: ok, SG min/max not available<lf>Driver 2: ok, SG min/max not avai<warning: maximal="" number="" of="" bytes="" per="" line="" exceeded!="" check="" the="" end-of-line="" settings="" or="" increase="" limit="" in="" advanced="" terminal="" settings.=""></warning:></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf></lf> -
M552 S0
M587 S"SSID" P"PWD"
M552 S1Viola …
new firmware and wifi server and new DWC all synced up ... sorry for the trouble guys - im back and with just a bit more gcode and duet firmware savvy - 1 Bite at a time ...
-
So any way to do G30 homing with doubletap?
-
M552 S0
M587 S"SSID" P"PWD"
M552 S1Viola …
new firmware and wifi server and new DWC all synced up ... sorry for the trouble guys - im back and with just a bit more gcode and duet firmware savvy - 1 Bite at a time ...
Glad you are up and running!
-
Thanks for the work on the rotating magnet filament monitor. I can confirm that the output looks better.
Please will you review briefly how the configuration is supposed to work? Perhaps post in the filament monitor section…
It seems like it auto-calibrates now the mm extruded per revolution of the magnet? In the previous version this was specified in the S parameter, but now its not clear to me as the documentation says '1 to enable' and later gives an example of 'S1.05 R30' meaning 'sensitivity 1.05, +/-30% error detection tolerance'. Also there's still the query about the Raa:bb form of the R parameter. My initial results (just running out the door so not much time to test!) are:[[language]] 2:01:00 PM M591 D0 Duet3D rotating magnet filament monitor on endstop input 3, disabled, sensitivity 26.68mm/rev, allowed movement 0% to 10%, check every 3.0mm, current position 284.4, measured sensitivity 24.92mm/rev, measured minimum 85%, maximum 132% over 273.1mm[[language]] 2:14:14 PM M591 D0 Duet3D rotating magnet filament monitor on endstop input 3, disabled, sensitivity 26.68mm/rev, allowed movement 0% to 10%, check every 3.0mm, current position 22.5, measured sensitivity 25.06mm/rev, measured minimum 85%, maximum 131% over 272.6mmmy sensor hob groove diameter measured 7.75mm so calculated circumference at the bottom of groove is 24.3mm
Thanks!
Rob. -
I have corrected the example given for firmware 1.21 and later.
-
The new "no moving Z before homing" is kind of a pain. I put the S2 in my config files, but the paneldue can't jog down in Z, which I occasionally would do without homing for testing, giving some clearance, whatever. Not the end of the world, I can make a macro to work around it. Just some general feedback.
-
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
-
Did you rename it to exactly DuetWiFiFirmware.bin? Use the System Editor page of DWC to check that it is there.
-
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
