Power recover wrong last position
-
Do NOT run Z-Homing - it will crash your print head into the bed!
I think what dc42 meant was to undo the "G1 Z3 F3000" move from your sys/powerfail.g.
You need something like "G1 Z-3 F3000" in sys/powerrestore.g - similar with retraction and extrusion (E4 & E-4).@dc42: I think repositioning Z is missing from the examples given in https://duet3d.com/wiki/Setting_up_to_resume_a_print_after_a_power_failure
Not sure if a G91 is required before the regular G-code can run again? -
My luck was that the print head did not crashed into the bed, only into the print. Ok, I'm making some changings and I'll keep you posted.
-
If you read the wiki page that I wrote on this subject, you should have seen this in the Limitations section at the start:
You must be able to re-home the printer (possibly using a different homing sequence from normal) with a print on the bed.
-
@dc42: I think repositioning Z is missing from the examples given in https://duet3d.com/wiki/Setting_up_to_resume_a_print_after_a_power_failure
Not sure if a G91 is required before the regular G-code can run again?Repositioning Z happens automatically, it's part of the code written to resurrect-prologue.g.
You do not need a G90 or G91 code at the end of the resurrect-prologue.g file because absolute/relative status is restored at the end of executing any macro file to the value it had at the start.
-
During the tests, I shut down and turn on the printer. So the thing is that the printer does not manage to run the line: G1 Z3 F3000. because I don't have capacitors or something else. So the print head is sitiing on the print untill I run the ressurect.g file. I have inserted G1 Z-3 F3000 into my sys/powerrestore.g file but still the head is starting way above the print and opens my
appetite for spaghetti. -
If you read the wiki page that I wrote on this subject, you should have seen this in the Limitations section at the start:
You must be able to re-home the printer (possibly using a different homing sequence from normal) with a print on the bed.
Yes, I have read it. So then I think i must implement the stall detection and home my Z by hitting the axis at the high end. Maybe on the future will be a solution for homing only the X and Y. But as I said, even if I home my Z, the print head is now hitting the print.
-
Whether the G1 Z3 command gets completed or not doesn't affect the restore position, because the restore parameters written to resurrect.g are the position before that command is executed. The last few lines of the resurrect.g file that you quoted in your first post are:
M23 cilindru5.gcode
M26 S48738 P0.000
G0 F6000 Z5.771
G0 F6000 X76.79 Y103.62
G0 F6000 Z3.771
G1 F6000.0 P0
M24You can see that the head is commanded up to 5.771mm, then to the correct XY position, then to 3.771mm which will be the height of the nozzle when the print was interrupted. It sounds to me exactly as if the printer has not been Z-homed when those commands are executed. On a Cartesian printer, the firmware sets the initial position to X0 Y0 Z0. So if you didn't home it, then if it stopped at Z3.771 and didn't manage to execute any of the G1 Z3 move when you powered off, it will be 3.771mm too high when the print is resumed.
If your Z axis can't move at 6000mm/sec (which is not uncommon), check that your M203 Z parameter is set to a lower speed that it can handle.
-
In my config.g I have M203 Z1250. If I set it to 6000 It will be horrible for my Z axis. Alot of skipping steps. But is not even trying to do something because I see it does not have energy when power outage happens. Another thing I have observed is that after the G28 command, the Z axis is rising by 5mm because this is my homez.g gcode and after the print fans are starting, Z is going up at the exact height where it should start printing, X and Y goes to their position and then i don't know why, something is telling to the printer to go down on Z by i don't know how much (maybe 3mm). The head is not hitting the bed, only the print.
-
I did one more test and I have filmed everything. So the last position of Z axis when I shut down the printer was 8.51mm. After I turn it on, the printer did G28 and sat at X0 Y0 Z5. After the print fan turned on, Z got to 10.62, X and Y to the last position and then Z droped to 8.63. The last part of ressurect.g is this:
M23 cilindru5.gcode
M26 S109990 P0.000
G0 F6000 Z11.226
G0 F6000 X102.91 Y76.74
G0 F6000 Z9.226
G1 F6000.0 P0
M24So 8.63-8.51= 0.12 This means Z should be up by about half of the layer height( I'm printing at 0.2). this is what values says but what I see is basically the head crushing into the object. Clearly, My Z is not with 0.12mm above the print.
-
M203 Z1250 is fine if that's a speed that your Z axis can do.
The head should go down by exactly 2mm after it moves to the correct XY position, that's what the code in resurrect.g commands.
-
What Z homing mechanisms are you using in homeall.g and in resurrect-prologue.g; and how are you ensuring that the Z height after homing in resurrect.g is exactly right?
-
This is my homeall.g
; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool on Sat Oct 28 2017 12:36:25 GMT+0300 (GTB Daylight Time); Relative positioning
G91; Lift Z
G1 Z5 F6000; Course home X or Y
G1 X-205 Y-205 F6000 S1
; Course home X
G1 X-205 S1
; Course home Y
G1 Y-205 S1; Move away from the endstops
G1 X5 Y5 F1000; Fine home X
G1 X-205 F360 S1
; Fine home Y
G1 Y-205 S1; Move Z down until the switch triggers
G1 Z-255 F1000 S1; Absolute positioning
G90; Tell the firmware where we are
G92 Z2.5; Uncomment the following line to lift the nozzle after probing
G1 Z5 F100Ressurect-prologue.g is:
;resurrect-prologue.g
M116
G28
;M83
;G1 E2 F3600"how are you ensuring that the Z height after homing in resurrect.g is exactly right?"
I have filmed with my phone the web page to see where my last position of the Z axis was before turning off the printer and also I have filmed where my Z axis is going after running ressurect.g file. And I have compared this values with those from ressurect.g file.You said something interesting and now I see. Yes, the ressurect.g file is telling to the printer to go down by 2mm. How can i make to not do this. I'm gonna do something. I'm gonna run again the experiment but before to upload the ressurect.g file I'll modify it in order to make Z to stay at the same height.
-
The resurrect.g file tells the printer to go initially to 2mm higher than where the print was interrupted. That's why it goes down 2mm at the end.
-
Yeah I know but it's like is not respecting this. Another huge problem that I have is that after X Y Z are positioned, the extruder is trying to extrude a huge amount of filament at a huge speed. The filament is getting grinded and that's all. Hmm, I really don't know where should I start with everything
-
The extruder thing sounds like you are mixing absolute vs. relative extruder moves: M82 and M83.
-
The extruder thing sounds like you are mixing absolute vs. relative extruder moves: M82 and M83.
i have M83 everywhere… Is power recover working for you?
-
What slicer are you using? Cura defaults to absolute extruder moves - but you are using relative in your code.
-
yes I was thinking about this that this is my problem. i ll give a try tmr using slic3r. but… i don t know what to say, there must be a solution for working with any slicer available.
-
So I've tried power failure feature with a gcode generated by slic3r and the extruder does not have any problems now. But the problem with the X axis persist. If i have G28 in ressurect-prologue.g the print will be resumed about 2mm into the print so it will hit the print. If I have G28 X Y the print will restart about 2 mm above the print.
-
Are you certain that the resurrect.g file was created when you lost power, and not some time earlier when you paused the print? If there isn't enough power to move the head up 3mm, perhaps there isn't enough power to save the resurrect.g file either. This line in resurrect.g:
M26 S48738 P0.000
tells me that the print was stopped between moves, rather than in the middle of a move as I would expect with a power failure. Also the header:
; File "cilindru5.gcode" resume print after print paused at 2017-11-06 13:04
says it was created due to a pause, not a power failure.
Try removing the M913 X0 Y0 from the start of your power fail script. This should be OK in beta 6 but wasn't in beta 4.