How to change something in file resurrect.g?

DSG

My board is duet2wifi rev1.04 using firmware 2.03

Phaedrux

I'm not sure if it's related, but there were some changes to the resurrection behaviour in the recently released 2.04 firmware update. Perhaps you can give it a try.

https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md

DSG

@Phaedrux the last update 2.04 just fix the select tool before resurrect-prologue.g is called.. I think it is not that I need, but I will try.
Thanks for your support.

Phaedrux

What's in your prologue file?

DSG

@Phaedrux prologue file just
M116
G28 X Y

Phaedrux

Thanks.

Perhaps @dc42 will have some insight.

blt3dp

How are you testing? Manually pausing or pulling the power? If your pausing it, what you're looking for might be in pause.g pause.g

littlehobbyshop

After a skim of the firmware, unfortunately this 2mm lift is hard coded and isn't configurable:

Line 2310 in /src/GCodes/GCodes.cpp:
https://github.com/dc42/RepRapFirmware/blob/2af0feba89833b8631dac6a3e662d4fc13f40410/src/GCodes/GCodes.cpp#L2310

The only way you would be able to change it is to fork the repo and re-compile your own version.

Perhaps you could also add an issue as a request for this to be configurable? No idea how that would be implemented and it may well be too much development for a fringe case.

T3P3Tony

@DSG what is your M911 command set to:

https://duet3d.dozuki.com/Wiki/Gcode#Section_M911_Configure_auto_save_on_loss_of_power

DSG

@T3P3Tony just turn off the motor X Y and retract follow the guide in wiki.

T3P3Tony

@DSG the guide in the wiki has a Z parameter added in the M911 command, hence why I asked

DSG

@T3P3Tony yes, wiki has guide that but I do not add the z lift code to M911, just turn off X Y motor and retract.

DSG

@littlehobbyshop please tell me how to compiled firmware. Thanks!

dc42

@DSG, can you tell me why you want to delete those 2 lines? Those lines are intended to move the head back to the point where it was when the power fail occurred, without scraping the top of the print.

The firmware build instructions are at https://github.com/dc42/RepRapFirmware/blob/dev/BuildInstructions.md.

DSG

@dc42 the lifting z about 2mm make the resume print not fit with the exist printed object. I have successed with remove lift z code in the resurrect.g not only pause state but also power failure. Have you added this mod in the next firmware version (user can figure the movement of print head)?

dc42

@DSG said in How to change something in file resurrect.g?:

@dc42 the lifting z about 2mm make the resume print not fit with the exist printed object.

I'm sorry, I still don't understand. What makes the 2mm lift unsuitable? That should keep the print head clear of the object that has been printed so far.

DSG

@dc42 I have 2 problems. The first is the print head lift 2mm and down 2mm before resume that make the gap (greater than layer height) between the print head and printed object. I think that problem comes from the z axis movement by belt. The next, the extrusion that has rised from calling resurrect-prologue.g before print head arrives at the previous location make the under extrusion when resume print. That are reasons I want to edit resurrect.g, disable lift the z and add gcode for extrusion after print head comes back. I have tried that by edit the resurrect.g manually and get success resume at pause/planning power off or power failure state. How to config that?

DSG

Compile the firmware with remove some code and add a code for calling powerfailure.g (made by me) for adjusting the extrusion before resume print that solute my problem.
Thanks.

TLAS

@dc42

Having recently been through this, I think it’s not clear that when you ‘pause’ a print and modify the resurrect file that you need to exit the print to get the resurrect file to take.

I kept modifying the file and just hitting resume and watching the printer try to print in mid-air. I ultimately got it, but from what I’ve been able to read here, that might have been the same problem and the z-code lift may have been misunderstood as the reason why the printer was not printing on the previous layer.

Not sure how to solve this in documentation, maybe just a bold somewhere that you need to restart the print and rehome to get it to take.

Awesome job on the resurrect sequence by the way. Wish I never had to use it, but things happen with big prints sometimes and it’s well implemented making problems recoverable.

Phaedrux

@TLAS Well the resurrect feature is intended for resuming after a powerloss, which implies the printer has been power cycled, not just paused.