G1 R1 X0 Y0 Z3 actually moves to X0 and Y0 - instead of the "last saved point".
Then it move 3mm down.
Then it seems to continue to the correct "last saved point" location (not sure if this is still from with resume.g or already the next commanded move from my print code).
Now it obviously crashes because the nozzle is too low.

This is repeatable. Print something for a few minutes. Pause. (I usually do a filament change or clear a heat-creep and command some manual extrusion to prime the nozzle). The Resume. Then crash (if I'm not quick enough with the E-stop).

I might have tweaked my config - but I don't see anything obvious in my version-controlled config files...@dc42 Should G0 R1 X0 Y0 behave the same as G1 R1 X0 Y0?

edit: I just flashed RC4 again - and the problem is gone. So this is a regression in RC5.

Strange, nobody else has reported this and I have similar lines in resume.g. I will test it again.

RRF restores the last print position automatically immediately before resuming. Using G1 R1 commands is optional, and allows you to control how it is done. G0 R1 should behave the same as G1 R1 except that on some machines (e.g. SCARA) the movement may not be linear.

Even though the G0 R1 and G1 R1 lines are not strictly needed, they should still work, at least if you are not using workplace coordinate offsets or tool offsets. As you are not using either of those, I don't know why they are not working properly. The negative Y coordinate is OK. I tested pause/resume in 2.02RC5 using this resume.g file:

I added beeps to my resume.g to check when the faulty moves are made:
The G1 R1 ... commands in resume.g are not correctly executed. The head seems to be moved to (0,0) in absolute coordinates (front left corner).

With RC4 this works as expected.
So this bug seems to happen somewhere during/before the execution of resume.g, because once we enter the resuming_1 state, it behaves correctly.HandleMCode for case 24 is pretty simple - so I suspect DoFileMacro again...

@resam, thanks for your analysis, that looks like the explanation. The odd thing is that I ran pause/resume tests on my delta, and I didn't see a problem.

I believe that I've encountered this same issue a few times. My resume.g is identical the one posted by @resam , though mine also contains a M906 to reset the idle current for the stepper motors (I set the idle current to 100% in my filament-change.g)

In my case, the nozzle crashing against the print has, I believe, caused physical damage when the part fan duct was shoved against the side of the print, and pressed hard against the wires from my heater and Pt1000 thermistor. (Apparently, smashing the side of a PT1000 where the wires come out can be bad for the PT1000.)

Note: I'm not trying to make any claim for the destroyed thermistor. I completely recognize that I'm using RC firmware and that's one of the risks I take. On the other hand, I'm hoping that @dc42 can get a fix for this particular issue out more quickly considering that it can cause physical damage.

I also have a problem with 2.02RC5. As you can see I have 2 tools defined, and for one of them I have Z offset.
When I try homing T1 Duet ignores Z offset (I go to 0 on end). 2.02RC4 works as intended.

@resam, thanks for your analysis, that looks like the explanation. The odd thing is that I ran pause/resume tests on my delta, and I didn't see a problem.

I believe that I've encountered this same issue a few times. My resume.g is identical the one posted by @resam , though mine also contains a M906 to reset the idle current for the stepper motors (I set the idle current to 100% in my filament-change.g)

In my case, the nozzle crashing against the print has, I believe, caused physical damage when the part fan duct was shoved against the side of the print, and pressed hard against the wires from my heater and Pt1000 thermistor. (Apparently, smashing the side of a PT1000 where the wires come out can be bad for the PT1000.)

Note: I'm not trying to make any claim for the destroyed thermistor. I completely recognize that I'm using RC firmware and that's one of the risks I take. On the other hand, I'm hoping that @dc42 can get a fix for this particular issue out more quickly considering that it can cause physical damage.

I'm sorry it may have caused damage. I've added a warning in the what's new file and also on the release page for 2.02RC5. I've already implemented a fix in the RC6 source.

I think I was just bitten by the resume bug. I was printing with some stonefil filament that is rather brittle. The filament broke midprint and I paused it so I could reload it, when pausing it dropped the print head to Z5 instead of raising it by 5, and I didn't really notice it as a problem. When I resumed the print it moved the print head diagonally back to the resume point and in the process smashed into the print popping it off the bed. No damage that I can see thankfully.

I've found why it doesn't allow you to do a G30 immediately after prox and distal homing. It calculates the XY position from the homed position, then when preparing the G30 move it has to calculate prox and distal positions back from XY. Because of a slight rounding error in the round-trip calculation, it thinks the prox and/or distal position is slightly beyond the homing switch limit. So it abandons the G30 move.

For 2.02RC6 I have saved the XY and arm positions in the position cache, so that it can bypass the calculation of XY from the arm angles. This allows G30 to be performed immediately after prox and distal homing.

The "Add test" move you added should work around the problem. Please can you explain what you mean when you said "Print test ok but impossible to put it in the right place because no absolute movements ...".

Alternatively you can use a regular G1 X... Y... move at that point to put the print head at a specified XY position, which is what my homing file did before I removed that command to investigate the problem with G30.

Humm of memory ... because the test of impression I had realized it on version 2.02RC3..4 ?
in short the impression started from my homing position,
it was not in the right place because no absolute movements

Last night my print stopped dead in it's tracks with the nozzle stopped in mid print. The DWC was apparently reset, because there was no history in the gcode console. There was no saved state file. All this sounds like it could be down to a power outage, EXCEPT that the hot end and bed were still at the temperature from the job, and M591 D0 reports the history between 64% and 95% as if the job were still in process. It's 2.0RC5 Maestro. I'm moving my UPS so I can plug the Ender into it.