@jltx you should add X0 Y0 to your two G1 R1 commands in resume.g. Also add Z0 to the second one.

@jltx

the wave function collapses and the cat is definitely dead.

Common wisdom: Never bet on a cat, they always know better…

Did multiple more tests, all of the combinations of:
OpenLoop:ClosedLoop
G30:G38.2
MainBoard:1HCL (probe connection)

MainBoard connected would get through my test without once sticking the probe.
1HCL connected always stuck the probe, but at random times. The most # of probes I was able to get through before the probe stuck was 781.

Also tried slowing down the probing speed, and playing with the pullback (M558 H###:####). none had noticeable affect in time before sticking, though it's so random it's hard to identify what makes a difference or what is just placebo.

@effnish thanks for confirming. This change is included in 3.6.0-rc.3 released yesterday.

@dc42 Thanks, that seems to have worked just fine. Using T1 I am able to execute G32 and get what seems to be the correct levelling (aka, it's within the normal values I expect to see when using T0).

In case it helps anyone else, I replaced the G30 calls in my bed.g with calls to this macro which should work for machines with just one tool or two tools:

@SanderLPFRG thanks, I'll flag this as solved.

RRF treats out-of-bounds errors differently between straight moves and arc moves. The reasons for this are largely historical. Originally, on some machines it was convenient to allow extrusion outside the bed (but without reaching physical endstops) because when printing a part that filled the bed, it didn't matter if part of the skirt was extruded outside the bed. Whereas G2/G3 were originally used only in CNC applications, where out-of-bounds movements were more serious.

@dc42 here the files, yes the report is the same with M400 in between.
config.g
test_microstep.g

@ironhydroxide it's still a bug so I've added this symptom to this issue https://github.com/Duet3D/RepRapFirmware/issues/1094.

For anybody looking in the future, that did not in fact work. I went all the way up to M570 H0 P60 T40 and still had spurious heater faults. https://github.com/Duet3D/Duet3Expansion/pull/23 seems to have really fixed it, without needing to change M570 from the defaults at all.

@caviara Are you seeing this movement show up in the X/Y position displayed by DWC?

@Chorca thanks for confirming! The fix will be includ idn the next RC or 3.6.0 stable release.

@davidjryan Thanks for reporting this. It will be fixed in the next version.

@jay_s_uk it's when babystepping in -Z. I've updated to 3.6.0 rc2 and the issue persists. I believe it has something to do with the bed mesh compensation thinking the machine is going outside its limits. Also, when restarting a new print, the babystepping value has to be increased with the previous value to get to nozzle at the correct height, and the reported z axis position will start to drift every time this is repeated (I'd expect this to get reset).

Anyhow, I've now run a first level calibration print and set the probe offset accordingly (g31 in the config) so I don't need to use babystepping for now. I'm also not entirely sure if this is an isolated 3.6.0 issue since I've only had to start messing with the babystepping after I've had a crash with disabled axis limits 😅

@marvineer What exactly are you seeing happen? As reported by dc42 he sees an initial diagonal move followed by a Y direction move for the homing move. Is that different to what you are seeing? Perhaps if you post a video of what you are seeing that will help? My understanding is that you should see what dc42 has reported and that is the expected movement.

@droftarts and @dc42 , thanks for explaining that!

Looks like in the "connecting fan documentation" there is a similar note (as what was explained to me above) for the Duet 2.. Perhaps indicating that is also applicable to (at least) the 6HC and 6XD would be sufficient.

@MaxGyver I believe I have identified the cause of these errors. If I am right, they only occur when the input shaping frequency is below about 12Hz, which would explain why nobody else has reported Code 3 errors since we released beta4.

Please try the new 3.6.0-rc.2+2 main board firmware binary from https://www.dropbox.com/scl/fo/nlkfneaas1osgtdw37s17/AIS_H0KSAKCmfYSjSRTSOAE?rlkey=ad4omnq36zkdz3wl8i7kthqqt&dl=0. You may keep your expansion board binaries at 3.6.0-rc.2 or upgrade them to rc.2+1 from https://www.dropbox.com/scl/fo/kj7gwwzxg5lhe26twph5z/AAdwkPCTYi6bcogLmIIIup4?rlkey=8oo6z5il7wzk2u5b7qpykf3qv&dl=0.

I've put new 3.6.0-rc.2+1 binaries at https://www.dropbox.com/scl/fo/kj7gwwzxg5lhe26twph5z/AAdwkPCTYi6bcogLmIIIup4?rlkey=8oo6z5il7wzk2u5b7qpykf3qv&dl=0. The change list since rc.2 is at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#reprapfirmware-360-rc21-unofficial-build.