Firmware 1.21 release candidate 2 now available
-
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?
-
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.
