Firmware 1.21 release candidate 2 now available
-
I have a BL touch and have had the probe type set to 5 and was using multi-touch and it works fine, what is the benefit of using type 9?
-
Some bltouch users had the problem of the bltouch extending too soon again after probing.
-
I updated, changed my probe type to 9, removed my M401s and M402s from bed.g, homez.g and homeall.g. Everything is working as expected on my IDEX cartesian.
Thanks for the feedback. Be aware the the multi touch Z probing is not compatible with bltouch in this release.
I don't use multi touch at this point, but I may check it out at some point in the future. I seem to get pretty good results with my setup without it. Maybe I got lucky and got a pretty consistent bltouch.
Larry
-
A few issues with this release have come to light:
- The new bltouch probe support doesn't work properly if you enable the multi-tap function, because it fails to deploy the probe before the second tap
- The multi-tap function only implements the recovery delay before the first tap at each probe point, instead of before each tap
- Support for the Duet3D rotating magnet filament sensor is not working
Is it possible to get multitap for Z homing?
-
Firmware Name: RepRapFirmware for Duet WiFi and Duet Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 1.21RC2 (2018-02-15 build 2)
WiFi Server Version: 1.21RC2
Web Interface Version: 1.20When i upload a file that is named fooprint(2).gcode and want to print the file it will say file does not exist
Error: M32: GCode file "0:/gcodes/26mmgauntbaseV2.gcode" not found
10:04:14 PMM32 0:/gcodes/26mmgauntbaseV2(2).gcode
any chance you might have a look into that? -
This issue has been raised several times already. It is part of the NIST GCode standard that parenthesis surround comments, therefore they are stripped out. The workaround is to surround the filename in double quotes. The latest beta of PanelDueFirmware already does this, so will the next version of DWC.
-
This issue has been raised several times already. It is part of the NIST GCode standard that parenthesis surround comments, therefore they are stripped out. The workaround is to surround the filename in double quotes. The latest beta of PanelDueFirmware already does this, so will the next version of DWC.
…or use square brackets instead.
-
Came here to report.
CoreXY with bltouch and multitouch probing enabled with Probe 5 (P5), prints and everything works fine. Also the web interface feels more responsive.
-
I just installed this RC so I have not yet reached the end of a print with this firmware but it seems that the slowdown issue here: https://www.duet3d.com/forum/thread.php?id=4045#p36659 still persists. I recently noticed that sometimes my machine would enter this state at the beginning of a print as well as consistently at the end (on RC1). It got stuck in this slow state with RC2 at the beginning of the first print I just started.
I expect that it will enter this slow state at the end of the print as well but if not I will be sure to report back.
-
On RC1, I got 3 of my simple switch filament sensors working, using the following configurations:
T0 M591 D0 P2 C3
T1 unused for now
T2 M591 D2 P2 C5
T3 M591 D3 P2 C5I am now getting errors that C5 is not acceptable. Is this correct?
With X, Y, and Z endstops connected what are the C numbers that I can use for 4 filament sensors?
If I went to sensor less homing, what would the C numbers be?
Can some C numbers be used with only certain types of sensors (P)?
Does it matter if an expansion board is present?
It looks like the pad printing on the boards and C numbers correspond as follows, correct?
X C0
Y C1
Z C2
E0 C3
E1 C4
E2 C5
E3 C6
E4 C7
E5 C8
E6 C9Sorry to ask so many questions but I'm having a hard time figuring this out from the wiki: https://duet3d.dozuki.com/Wiki/Gcode#Section_M591_Configure_filament_sensing
-
Thanks for spotting this, it will be fixed in RC3.
-
After installing RC1 (at least that is when I noticed), my machine stopped reporting layer times and therefore estimates based on layer time. This issue persists in RC2. My gcodes are generated using KISSlicer. This may have started because I began using Z hop in Kisslicer (an no FW z hop) since it can filter hops out for really short travel moves.
-
I was going to submit a new bug report, but my machine is doing this SLOW CRAWL right now – it's a slow state of 12 hours into 15 hour print. Which is really frustrating. The DWC disconnects -- I don't know if there is away to save the print as I know where it is,
-
I was going to submit a new bug report, but my machine is doing this SLOW CRAWL right now – it's a slow state of 12 hours into 15 hour print. Which is really frustrating. The DWC disconnects -- I don't know if there is away to save the print as I know where it is,
Which Duet are you using? Does the machine print each move at normal speed but pause between moves, or does it do moves continuously but at slower than normal speed?
-
I have the Duet Ethernet Duex5 7 inch LCD. And 2 external driver pins used as well. It moves very slowly in jerky fashion.
It seems that it's thinking a lot for each move, so DWC becomes unable to connect. Last time this happened it was doing another 12+ hour print but it was quad color, I saw checksum errors on the screen, so I figured it was a bad SD card, and I swapped SD cards, and was able to do 20 hour prints since. It looks like it started doing it pretty late into the print – I have 19 puzzle pieces on the bed and the artifcats of this movement is only 2 -- so I caught it in time to save the other 17.
I was finally able to connect to DWC -- pause the print, and it saved resurrect.g -- then I adjusted my homing (z probe points are away from the print, and the print was not tall enough to bother the gantry system. I was able to trigger a stop to reboot it -- then I homed it -- then did g32 with the H value set high so the dual lead screw compensation can run (can that be saved as part of resurrect, my machine when powered off -- Z doesn't move at all) -- I'd like to just save Z position, and any lead screw adjustments which were made.
It's printing now -- and looks like I was able to recover most of the print
thanks -
I think as I look at the artifacts it is doing each straight line move at normal speed, but then sits there creating a blob. There are a lot of curves in this print, so it was doing those at a jerky pace since I believe curves are a combination of small straight lines. Hope that helps
-
Thanks. Can you confirm that you are definitely running firmware 1.21RC2? Please check using M115.
-
in DWC:
Firmware Name: RepRapFirmware for Duet WiFi and Duet Ethernet
Firmware Electronics: Duet Ethernet 1.02 or later + DueX5
Firmware Version: 1.21RC2 (2018-02-15 build 2)
Web Interface Version: 1.20-RC3M115
FIRMWARE_NAME: RepRapFirmware for Duet WiFi and Duet Ethernet FIRMWARE_VERSION: 1.21RC2 ELECTRONICS: Duet Ethernet 1.02 or later + DueX5 FIRMWARE_DATE: 2018-02-15 build 2 -
Thanks. I've had similar reports from a small number of Duet Ethernet users, but not with 1.21RC2. You've confirmed that this issue hasn't gone away in the new combined Duet WiFi/Duet Ethernet firmware.
If it happens again, please try the following:
1. See if you can connect to a PC via USB and Pronterface or a terminal emulator and run simple non-movement commands e.g. M115.
2. If so, send M552 S0 to stop the network interface, then wait for the acknowledgment. See if normal speed is resumed.
3. If normal speed is resumed, send M552 S1 to start the network interface.
Alternatively, if you are able to connect DWC you can just send M552 S0 and see if normal speed is resumed. Obviously you will lose the connection, and you will need to restart the network from USB or PanelDue.
-
My duet is connected to constant 5V power, so it's always "on" – so does it make sense to run disable/enable network at start of each print? Or include those commands in my power off/power on macros? Is it a side effect of it being on all the time?
