Firmware 1.21 release candidate 2 now available
-
@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
-
It might be possible already:
- Start with a plain G30 at whatever XY point you want
- Follow it with e.g. G30 X100 Y100 S0 (if that doesn't work, G30 P0 X100 Y100 S0 might)
Warning: I haven't tried this!
-
David, can you explain what behavior we should expect?
Will the second G30 perform multitapping or not? (I tried without P0 but did not multitap) -
I am closing this thread because 121RC3 is now available.
