@phaedrux Hello again! I ended up doing a complete fresh reinstall from the configurator then made sure I was using the latest stable release.

Good news is I am now connected to DWC 3.3.0, bad news is I have a new issue here.

M122 printout is being flagged as spam by Akismet. I will try and snippet the relevant.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0 running on Duet WiFi 1.02 or later + DueX5

...

Error status: 0

...

=== Network ===
Slowest loop: 15.22ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
- WiFi -
Network state is running
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address 48:3f:da:75:a8:d7
WiFi Vcc 3.36, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 26024
WiFi IP address 192.168.0.74
WiFi signal strength -63dBm, reconnections 0, sleep mode unknown
Socket states: 0 0 0 0 0 0 0 0

@jay_s_uk Thanks! Now they're actually in sync that should be much easier through DWC. Back on track

@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!

@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

@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

@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 I can't and haven't implemented it. My Z does lift 5mm before homing X and Y as a precaution but I'd expect that to be added to the saved Z height in resurrect.g. as per standard operation.

Here's my save state in config.g:

; Power failure save state
M911 S21.0 R23.0 P"M913 X0 Y0 Z30 G91 M83 G1 Z3 E-2 F1000" ; Save if V<=21V, resume if >=23V, run command in quotes

Here's my resurrect-prologue.g

; RESURRECT PROLOGUE
; Called by M916 to resume printing from save state after power loss
; https://duet3d.dozuki.com/Wiki/Setting_up_to_resume_a_print_after_a_power_failure

; Experimental. Set Z to Z+3 to account for lift when powered down
var zSaved = Z
G92 Z{zSaved+3}

M291 P"Resume from save state?" R"POWER FAIL DETECTED" S3
G28 X Y ; home X and Y, hope that Z hasn't moved
M291 P"Resuming print" S1
M116 ; wait for temperatures
M83 ; relative extrusion
G1 E2 F3600 ; undo the retraction that was done in the M911 power fail script

I tested it by doing a calibration cube and flicking the switch halfway through. 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.

EDIT: and the Z height readout in DWC showed about the expected height. I didn't check the exact value but it was non-zero, in the 12-13mm range.

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

https://duet3d.dozuki.com/Wiki/Setting_up_to_resume_a_print_after_a_power_failure#Section_Setting_up_the_sys_resurrect_prologue_g_file

Yes, that's the documentation I was following (should've linked). I'm homing X and Y only as running a CoreXY with stable Z and "hoping Z has not changed". However the vertical lift in M911 isn't accounted for in the example resurrect-prologue.g.

I'm now looking at the Object Mode Documentation and wondering if I should be getting Z from move.axes[].machinePosition

So I'm approaching this with some partly-remembered prior experience with Arduino and Python, which is to say I am a good candidate for "A little knowledge is a dangerous thing".

Short version: I want to take the current Z position, increase it by n and apply that value to Z as current position, i.e. offset the Z value by n without moving. I expected this to work somewhat like so, following the iteration form:

G92 Z{Z+n}

Then I tried:

var zSaved = Z
G92 Z{zSaved+n}

That didn't work so I'm assuming Z isn't actually what I'm looking for but some other system value that is then read as Z? I've tried looking at the object model but can't say I'm too familiar with that aspect (n00b alert).

Background:
Essentially looking through the write-up for power failure and resurrect I noticed that after lifting the nozzle in the save state this offset isn't accounted for when resuming the print. So the order of operation is:

Detect power loss
  → move up n mm
Restart after power resumes
  →  homes X and Y
    →  Z is read from sys/resurrect.g  G92
      →  no Z correction made (this I want to fix)
        →  starts print but n mm higher than it left off.

Probably a very simple answer eluding me but thanks for your time

@mintytrebor I'm having the same installation error as stuartofmt. I tried installing A.0.8.20 on RRF 3.3 via the settings "upload system files" button but it just goes "upload complete" and doesn't bring up any instructions or similar.
There's now a folder in Sys which has the .json.

@jay_s_uk Thanks! Now they're actually in sync that should be much easier through DWC. Back on track

Solved... I think???

Essentially I went crazy and uploaded the binaries to both /sys and /firmware and attempted M997 S0 over terminal. Every time it said something was missing I'd make sure it was present in both.
Then I did the same for M997 S1.

Now my DWC is 3.3.0 and RRF is version 3.3 (2021-06-15 21:44:54)

I... I think everything is alright now...

This was interesting coming from a background of Marlin and Octoprint/Pi. I think I had this incorrect idea that everything ran from the SD card, so if I got the file structure in there right then everything else would fall into place. That wasn't the case. Instead the SD works more as a directory and the Firmware itself runs on the Duet chip. So I'd given it the files but hadn't told it to implement them onto the board.
So by using M997 and essentially forcing it to upload the right stuff I think I finally have both my firmware and DWC where they should be.

@Phaedrux is that correct? DWC 3.3.0 and RRF 3.3 (2021-06-15 21:44:54) ? Anything else I ought to get set up now? Sorry for summoning you in, I just need a pair of sane and expert eyes to confirm I'm actually all set