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