I don't suppose you could update to 3.5.4 to test, or the recently released 3.6 release candidate?

@Leonard03 Are you still using RRF 3.6.0-rc3+2 firmware?

Ian

@Leonard03 Okay, thanks for testing! Back to the drawing board...

Ian

@Leonard03 We are homing in on a bug, related to applying the skew compensation when axes are homed at the same time. In 3.5.4, this worked correctly, but now doesn't seem to.

The difference is in how the skew compensation is applied. "resurrect-prologue.g" needs to run just X and Y homing, it runs home X, then home Y. Skew compensation is applied to X once Y is homed. In homeall.g, X and Y are homed at the same time, but doesn't seem to apply skew compensation until after the first move, which is when the axes move to resume the print, so will be in the wrong place.

A workaround for now is to modify your homeall.g so it homes X, then Y, rather than both at the same time. Either replace the X and Y homing lines with the lines from homex.g and homey.g, or as @fcwilt mentioned earlier in this thread, replace them by calling the homex.g and homey.g macros, eg

M98 P"homex.g"
M98 P"homey.g"

Then it should resurrect in the same place. @dc42 is working on a fix.

Ian

@R006 stall detection is not relevant to detecting open-load conditions, however the driver-warning.g file should catch it if you are running a sufficiently recent version of RRF.

@Alijambo73 your PSU DC out negative terminal should be connected to VIN- on the Duet, so it makes no difference.

@ironhydroxide did you have a chance to try this build? We plan to release 3.6.0-stable this week and I would like to include a fix for this issue in it.

@Leonard03 please post your resurrect.g file (after pausing) and your resurrect-prolog.g file.

@Leonard03 Thanks for your continued testing. Was the calibration cube on the right caused by a pause/resume, or by a "power failure" (please explain how you did this!)?

I've just been testing this too, and find that I was able to provoke the bug when using G30 and skew compensation in 3.6.0-rc.3, but that it works correctly in 3.6.0-rc.3+1.

With one bug resolved, I think there's something else going on when you pause and/or 'simulate a power failure', then resume/resurrect. It would seem that skew compensation is not applied, or the position is reset. When a print is paused, or there is a power failure, RRF creates a 'resurrect.g' file in the /sys folder, which is then used to return the tool to the correct position a resume the job. It could be that it is not applying skew compensation at the correct point during this.

Could you:

1. Start a print normally.
2. Pause the print, or 'simulate a power failure'
3. Send M556 to show the current skew compensation setting
4. Copy the 'resurrect.g' file from /sys and post it
5. resume the print and see if it shifts
6. Post your pause.g, resume.g and the output of M556 (in case it has changed, or isn't being applied any longer)

Thanks!

Ian

@DocTrucker yes it's the connector block will update when I next get a chance