@dc42 I don't see one in the list of system files, I don't think I have one.

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

@droftarts @chrishamm

I can confirm that the re-racking occurs whenever a G92 is executed. No need for a G28 X or M98 P"homex.g".

I can send a G92 X0 (or any other axis letter) and watch it occur in the DWC.

@droftarts thanks - I've been wrestling with M598's a lot over the last few days - trying to get parallel tool changing working (not actually parallel printing).

I am flipping between two motion systems - trying to kick off a process on the other motion system just before the current motion system finishes.

I'm getting close to getting it working - but I've at the moment I've more or less given up on using M598's. - as when you keep alternating between using them on different motion systems (a) sometimes they work fine, (b) sometimes they wait for around 20 seconds for no apparent reason. (c) Sometimes they hang and finally (d) sometimes they seem to just finish even though the other motion system is working on stuff.

I tried using axes machinePosition to tell what the opposite gantry was up to - but that doesn't seem reliable either.

So I have settled on using global variables to flag when the other motion system is parked - so when it is safe to proceed.

Seems to be working ok so far.

oh wow, sometimes the obvious...
Thanks!

@dc42

Unfortunately the error didn't occur so far (after 100h printing).

But what I can add: When the error happened, soft resetting the printer (STOP on PanelDue) did not recover the 1LC. I had to unplug the power to recover the 1LC which was not responsive anymore.

@dc42 Thank you very much for taking this issue in consideration! I had really low hopes that this can be fixed because I don't now how many users have this kind of setups and because I'm using the Duet 2.. well, I have no words 😄 Thank you again and congratulations for your efforts and for supporting the Duet 2 boards for so long! ♥

@dc42 Yes, I do use M556. It should be in the config I posted earlier, but I just realized I copied the wrong one, sorry! I'll update it right now.

Desktop 2025.03.31 - 20.00.53.04.mp4

@sebkritikel thanks for your report. The causes we found for Code 2 and Code 7 halts have been fixed in 3.6.0-rc.1.

In SBC mode, thanks for looking at it!

@chrishamm thanks i missed that on that general page
26f21520-259a-4bdb-b670-a0ebeb48d434-image.png

@Serbitar I suspect that pausing from a tool change macro is going to cause problems. I'm not even sure what the correct resumption point should be if you do that. Having said that I've also no idea what the correct way is to handle a failed tool change. I tend to treat them in effect as a fatal error on my e3d toolchanger and just abort everything, but I can see how on printers that may have "expected" fails during a change this is not really a good solution.

@achrn It should be available via the package feeds as well now.

@moth4017 if the bed isn't completely flat then probing just 3 points may not give the best level, for example one of the probe points might be on a high spot and another on a low spot. If you probe more points then RRF chooses the plane that minimises the total RMS deviation at the probe points. This in turn is likely to reduce the mesh compensation needed.