@ironhydroxide I'm sorry to bother you again, however I've had to revert one of the earlier changes I made to fix this issue because it had an unfortunate side effect. I think the issue should be fixed without that change; however I would be grateful if you could test the candidate 3.6.0 firmware for the 1HCL which is now at https://www.dropbox.com/scl/fo/etf8gf0vxx8ro102juita/AHzXcQJL_3Io_1C4LuDwpxI?rlkey=1hbgwbogzy1r44y1897a7kqds&dl=0.

@MaxGyver thanks for your report. Please do some more tests to make suite sure that the disconnect is reproducible, and that it only occurs when IS is set to 12Hz (or lower if you prefer) and not when it is set to 13Hz. Then start a new thread about this disconnect issue. As @gloomyandy suggested, please include the result of M121 B# where # is the CAN address of the 1XD board.

@dc42
4 prints in a row, and currently running big part (6 hours already) - no problems observed.

Thank you (and your team) again for your work!

@wschadow have you tested 3.6.0-rc.3 yet to see if this issue is resolved?

@droftarts @gloomyandy, as a follow up, I think I've found the culprit, I disconnected the boxturtle and booted the printer up all remaining boards connect without issue, with it connected I had a cascade failure of all boards but the mainboard, I belled the boxturtle cable out and it was fine, I did however find the positive and both CAN wires retracted in the plug, I've made good and now the printer is up and running the same print now, fingers crossed it completes with no issue!

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

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

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