I've discovered that the disconnection always happens at a certain Y position. I'd assumed it was an issue with the cable to the X board since that was the one reporting the issue, but it seems even if the y or z boards disconnect, if it tried to do something on the x board it only reports an error on the x, not on the other boards. M122 doesn't show a reset on the other boards either though, so it's just a guess that it's actually the Z board disconnecting not the X (although that does cause the X to disconnect because they're chained).

So I'm going to try replacing the canbus cable on the Y axis which runs to the Z board since I think it may have a break in it since it has a poor connection in a particular Y position.

@dc42 M122 returns

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6XD version 3.5.0-rc.3+ (2024-02-26 21:13:26) running on Duet 3 MB6XD v1.01 or later (standalone mode)

And the settings show this:

I've updated DWC to 3.5.0-rc.3 but that hasn't helped.

@dc42 I have tried updating again, in-case I had the wrong files, but still not luck. I can't see a DWC update file, do I need one? It's currently on 3.5.0-rc.2 whereas all other boards are now on 3.5.0-rc.3+

@dc42 No luck unfortunately, I updated mainboard and all expansions but behaviour is the same.

@dc42 Great, thank you

This is the macro I'm using now, within the macros folder contains:

M220
M203
G1 X50 F60000
M220
M203
G1 X-50 F60000
M220
M203

If I run M220 S1 and then run it, it returns:

M98 P"0:/macros/test.g"
Speed factor: 1.0%
Max speeds (mm/min): X: 60000.0, Y: 180000.0, Z: 160000.0, E:, min. speed 30.00
Speed factor: 1.0%
Max speeds (mm/min): X: 60000.0, Y: 180000.0, Z: 160000.0, E:, min. speed 30.00
Speed factor: 1.0%
Max speeds (mm/min): X: 60000.0, Y: 180000.0, Z: 160000.0, E:, min. speed 30.00

If I run M220 S100 and then run it, it returns:

M98 P"0:/macros/test.g"
Speed factor: 100.0%
Max speeds (mm/min): X: 60000.0, Y: 180000.0, Z: 160000.0, E:, min. speed 30.00
Speed factor: 100.0%
Max speeds (mm/min): X: 60000.0, Y: 180000.0, Z: 160000.0, E:, min. speed 30.00
Speed factor: 100.0%
Max speeds (mm/min): X: 60000.0, Y: 180000.0, Z: 160000.0, E:, min. speed 30.00

But both both visibly run at 100% speed

@dc42 The macro is within the macros folder, not within sys. M203 returns 60000 which is the max speed for this X axis as set in the config. So I can't see why it's not working.

@gloomyandy Sure, if I run M220 S100, and then G1 X50 F60000 it runs at the requested speed. If I do M220 S1 followed by G1 X50 F60000 then it runs very slowly. So the command works properly in this context.

If I run M220 S1 in DWC and then run a macro, which only contains G1 X50 F60000, it moves at full speed not at 1%. If I call M220 after that macro it confirms the speed is set at 1%

@dc42 Thank you both.

I'm finding M220 isn't affecting speeds inside of any macros. It does work for individual moves though.

@jay_s_uk I'll give it a go, thank you. What's the downside to using high resolution segmentation? Presumably it uses more processing power?

@dc42 This is working, thank you. It is now calling driver-warning.g for pre-stall, and driver-error.g for stall!

It would be useful to understand how these work better. If I have a macro which performs a sequence of moves, and one of those moves triggers a pre-stall, does the driver-warning.g code get injected after the move it's currently carrying out? And after that it will continue the macro?

When pre-stall is triggered I would like to drop the speed for the move currently being carried out. From my testing using M203 it seems this isn't possible, since it will only get dropped for the following move and not the current one which triggers the pre-stall.
Alternatively, I could stop the move and quit the macro entirely and rerun a slower version of the same macro. Again, from testing I've found I can't do this, as an M99 in driver-warning.g doesn't exit the moves macro, I wonder if it just exits the warning macro?

Happy to expand upon any of the above points. Thank you.