Firmware 1.21 release candidate 2 now available
-
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?
-
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.
I think you may have missed my comment reporting that this persisted for me on RC2 as well. It is on the previous page of the thread.
I can also confirm that mine still does this at the end of prints and often when idle.
-
I just installed firmware RC2 and also the WifiServer RC2. It seems like I'm having FTP issues again.
[c]wget -r -nH ftp://10.0.0.42/[/c] just hangs at trying to transfer/load [c].listing[/c].
As soon as I execute wget, DWC gets a request timeout. After a few seconds I can reconnect with DWC, but wget still hangs and I have to kill it.
M122 doesn't show anything - not even an active FTP socket.The console on PanelDue shows the well known message that it (re-) connected to my WiFi, no error message, just that it is connected now.
Reverting back to WifiServer 1.21RC1 solves it.
-
Thanks for the report, added to my list to investigate.
-
Just as a datapoint - I installed RC2 over RC1 on DuetWiFi and did a quick G32 calibration and test print on my Kossel Mini. All when well.
-
good morning, 5 days ago I updated the duet to 1.21rc2 and for more that I change the config.g the hot bed to pid keeps showing up in bang bang, I do not know what file to play to change it to pid, in 1.20 and 1.19 it could change without problem, what may be happening?
-
The bed heater will run in PID mode if you have a M307 command for it that includes the B0 parameter.
-
Currently iam printing a lot of parts over night, i think the funktion of Enable autosleep in DWC does not work correctly if not at all.
Came to the Printer in the morning and it had still the printing tempretures on the nozzle an bed. -
@dc42, here's a video showing the pause problem I reported earlier. The first pause happens when it moves to the right side to start the infill. You can see on the resume it moves back into place, then for some reason moves slowly left, then back into position and continues. I pause again during the infill, and you can see another move to the left and back again, though this one quicker. This is easy for me to reproduce.
https://www.youtube.com/watch?v=22Rw0M8L6tI
This is my resume.g, nothing fancy.
M83 ; relative extruder moves
G1 R1 X0 Y0 Z2 F6000 ; move to 2mm above resume point
G1 X0 Y0 Z0 R1 ; lower nozzle to resume point
G1 E12 F3600 ; undo the retraction from pause.gand this is the resurrect.g file it created
; File "0:/gcodes/8mm socket wrench.gcode" resume print after print paused at 2018-02-25 18:05
M140 P0 S115.0
G10 P0 S270 R170
T0 P0
G29 S1
M98 Presurrect-prologue.g
M106 P0 S0.00
M106 P2 S0.00
M106 P3 S0.00
M106 P4 S0.00
M106 P5 S0.00
M106 P6 S0.00
M106 P7 S0.00
M106 P8 S0.00
M106 S0.00
M116
M290 S0.000
G92 E0.00000
M83
M23 0:/gcodes/8mm socket wrench.gcode
M26 S288869 P0.000
G0 F6000 Z4.799
G0 F6000 X223.19 Y198.95
G0 F6000 Z2.799
G1 F3600.0 P0
M24 -
Can you explain exactly what you think is wrong in that sequence? Also I will need the GCode file you were printing so that I can correlate it with the resurrect.g file.
-
Can you explain exactly what you think is wrong in that sequence? Also I will need the GCode file you were printing so that I can correlate it with the resurrect.g file.
The nozzle moves to the left after resuming, then back to where it should be. You can see the nozzle drop, then at 13 seconds in the video slowly move left the first time, then back to where it should be, and continue. That move is not correct.
Here's the gcode file. I don't know if the resurrect file has anything to do with it, but I didn't notice this behavior before that bit of code was added to the firmware.
-
@dc42, here's a video that shows the issue much better.
Instead of moving straight back after the resume, it goes diagonal across the square, then back to the position it should have moved to.
It looks like when it resumes, it's inserting the next before the current move.
-
Thanks, that's much clearer. Can you share the resurrect.g file that was generated, and the original GCode file? The resurrect.g file will give me the exact offset in the GCode file at which the pause occurred.
-
I'll have to recreate it again, have a print running atm and have paused since. I'll recreate and upload it in a little bit.
The gcode is pretty simple, just a bunch of this…
; layer 17, Z = 3.400
; inner perimeter
M204 P 600
G1 X175.600 Y224.400 F18000
G1 Z3.400 F1200
G1 E0.4000 F3600
G1 X175.600 Y175.600 E1.5419 F2700
G1 X224.400 Y175.600 E1.5419
G1 X224.400 Y224.400 E1.5419
G1 X175.600 Y224.400 E1.5419
G1 X175.600 Y224.200 F3600
; outer perimeter
M204 P 600
G1 X175.200 Y224.800 F18000
G1 X175.200 Y175.200 E1.5672 F1800
G1 X224.800 Y175.200 E1.5672
G1 X224.800 Y224.800 E1.5672
G1 X175.200 Y224.800 E1.5672
G1 E-0.4000 F3600
G1 X175.200 Y224.600 F3600
G1 Z3.700 F1200 -
recreated again, http://rznt.com/resumebug.zip
-
Thanks. I believe I have identified the problem and fixed it; so please can you test again with 1.21RC3 when I have released it.
-
I scanned and did not see it, sorry if this is working as intended. I use the Z probe for homing Z. With multi-probe enabled, it still only probes once when homing Z. When I run bed.g, it probes twice (or more) as needed, though.
-
I think that's intended, but it'd be nice to have multi tap when homing z
