Offset Axis and Re-Assign Value?

T3P3Tony

@samanthajaneycake said in Offset Axis and Re-Assign Value?:

. My Z does lift 5mm before homing X and Y

@samanthajaneycake said in Offset Axis and Re-Assign Value?:

Resurrect seemed to go okay but as it approached the saved position it lowered 5mm to counter the Z raise during homing but not the 3mm to counter Z raise in save state.

this feels backward to me (i.e. i would expect anything in the power fail script to be accounted for, even if the stuff in the homing was not) however with fresh eyes this morning I realised that you don't need to use variables at all. if you want to undo the 3mm then use this in the resurrect-prologue.g

G91 ; set to relative positioning
G1 Z-3 ; drop Z by 3mm
G90 ; set to absolute positioning

So assuming the G92 step that happens automatically in resurrect.g is working correctly then the Z position would be set by ressurect.g and this just removes 3mm.

dc42

@samanthajaneycake said in Offset Axis and Re-Assign Value?:

var zSaved = Z G92 Z{zSaved+3}

If you really do need to do something like that, the command would be:

G92 Z{move.axes[2].userPosition+3}

Does the tool in use have a Z offset of 3mm? That could account for why you need to adjust the Z height, if you are unable to home Z in resurrect-prologue.g.

SamanthaJaneyCake

@t3p3tony Afternoon!
It did the same thing today, having implemented the regular relative move you suggested. In fact it seemed to go down the 3mm then back up again for printing (in the air).
Isn't this all because the resurrect.g G92 is called before the relative move so any relative moves will be made in relation to that saved Z, thus it automatically undoes them before printing?

It says "Z=4.99"
But it's really Z=4.99+3 (7.99)
We say "Go down 3"
It thinks "Okay, 4.99-3 = 1.99, that's where I am"
We say "resume printing"
It says "I was printing at Z=4.99, so I gotta go back up by 3"

Thanks @dc42 for that! I'm going to give that a shot and see what happens. My tool doesn't have a Z offset.

T3P3Tony

@samanthajaneycake very good point. This is not working as intended, the conditional gcode method that you suggested may work around it but I need to add this to the list to investigate further to see whats going on.

SamanthaJaneyCake

@t3p3tony The position is written to resurrect.g before the Z move is made according to the Save State in config.g, right? This makes sense as the position on the bed is theoretically more important, but as one can't work properly without the other I think we need to make sure there's a way to account for the discrepancy.

Will report back with whether the command works

SamanthaJaneyCake

@samanthajaneycake
Report on actions:

Replaced all experimental movement compensation commands with G92 Z{move.axes[2].userPosition+3}
Switched off when on Z=4.99
Z physically ~3mm above print
Left for 10s then powered on. Z reads as 0.00
Initiated resurrect.g, Z=10 while homing (now 13mm above print)
After homing print resumed. Reads as 4.99, physically looks to be printing at a bit below, causing a bulged layer

I note I set my Z current to 30% to maximise on available power. This is because I'm running a Voron 2.4 build so have 4 rather beefy Z motors. They're also geared down a further 1:4 by the V2.4's belt reducer. As such I felt safer not losing as much accuracy to the motors settling on a full step. I'll play around with the current percentage and see how high I can get away with in case that could be the cause of the squished layer. More testing needed!

Going back to analysing the why, this is my resurrect.g. I've annotated as seemed fitting.

; File "0:/gcodes/Restart Test.gcode" resume print after power failure at 2021-10-27 17:34
G21
M140 P0 S65.0
T-1 P0
; Note here is where it sets the current position. This value doesn't account for the 3mm raised. I paused at Z=4.99
G92 X166.194 Y169.381 Z4.990                 
G60 S1                             ; This is interesting, I'll look into it further
G10 P0 S200 R200
T0 P0
; And here we actually run the settable commands
M98 P"resurrect-prologue.g"          
M116
M290 X0.000 Y0.000 Z0.000 R0
T-1 P0
T0 P6
; Workplace coordinates
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
M106 S1.00
M106 P1 S1.00
M116
G92 E0.00000
M83
M486 S0 A"CalibrationCube"
M486 S0G17
M23 "0:/gcodes/Restart Test.gcode"
M26 S62086 P1.515 X180.685 Y183.867
; Interestingly here it seems to raise it 2mm in order to clear top
G0 F6000 Z6.990
G0 F6000 X166.194 Y169.381
; Then drop down back onto the print
G0 F6000 Z4.990
G1 F2010.2 P0
G21
M24

dc42

@samanthajaneycake I think this is what is happening:

When power is lost, RRF records the nozzle coordinates, file position and a lot of other data about the state of the printer
The intention is that in resurrect-prologue.g you re-home the printer. For a Cartesian or CoreXY style printer, this typically requires a homing switch at Z max.
You are not homing Z in resurrect-prologue.g, therefore the Z coordinate is as resurrect.g sets it, which is the Z height at which power started to fail
You attempt to raise the head 3mm in the power fail script. It looks as though you are successful in raising the head (which is unusual - in most printers there is insufficient reserve power to raise Z more than a fraction of a mm). However, it may be that the printer doesn't manage to raise it by quite as much as 3mm before there is insufficient power. This could account for why the print resumes slightly low.
Another consideration is that when you power a stepper motor and its driver off and on again, it will jump to a near multiple of 4 full steps (not just one full step) that match the phase currents. Loading may cause it to prefer jumping one way rather than the other, e.g. if the motor is supporting the weight of a bed then it may prefer jumping down 2.5 steps to jumping up 1.5 steps. This could also account for why the print resumes slightly low.

SamanthaJaneyCake

@dc42 All correct insights. In my case I'm running a Voron 2.4 build so no bed plate weight, just a lighter gantry, and the gearing down of the Z motors means I'm a bit less worried about the full micro step issue as it is by ratio a smaller final Z distance The "four full steps" however is worth further consideration.

I think my PSU holds enough residual current to give it a decent boost as it's about twice as powerful as I need, hence why it manages to raise Z noticeably (looking at the cubes I test I reckon about 2.6mm). I completely agree that the power likely cuts out a bit too early to complete the full raise so I have been following another thread and ordered up some 10,000 uF capacitors to stick across the power input to try and store a bit more juice.

The root issue of not homing is still valid though. There are many people who don't have the space or ability to mount an upper Z EndStop but more importantly the documentation mentions continuing without homing as a theoretical (but not recommended) possibility. So having a way to cover that base for those who need it seems wise.

Your suggested code has worked perfectly for that so thank you!

T3P3Tony

@samanthajaneycake said in Offset Axis and Re-Assign Value?:

The root issue of not homing is still valid though. There are many people who don't have the space or ability to mount an upper Z EndStop but more importantly the documentation mentions continuing without homing as a theoretical (but not recommended) possibility. So having a way to cover that base for those who need it seems wise.

Agreed, we can't take into account a indeterminate amount of Z raise, but taking into account the commanded amount should be done.

@samanthajaneycake said in Offset Axis and Re-Assign Value?:

hence why it manages to raise Z noticeably (looking at the cubes I test I reckon about 2.6mm)

For now, until your big caps arrive, how about adjusting the Z raise to 2mm - then it should work every time and at least you will have consistency.

KennethR

@T3P3Tony

I know this is an old topic but I think it makes sense asking in here anyway.

I am on an old firmware(2.03C beta, dated before this thread was started). Was the issues of using resurrect without homing Z-axis solved in later versions, or is the best shot still to use the code provided in this thread?

The reason I'm not just simply updating the FW is that I purchased a pre-built printer and never did a FW upgrade on a Duet controller, and I am currently in a situation where any downtime because of me doing something wrong in the FW upgrade process would be really bad.

Best regards
Kenneth

KennethR

@KennethR

NOTE: I found an easy fix for the issue and have created another post on my remaining problem. Please ignore the above post(I cannot edit it anymore)

BR Kenneth