Configuring Pre-Stall

dc42

@jjem please try the new firmware at https://www.dropbox.com/scl/fo/p0136wx04h8xf6ejwdnn9/h?rlkey=efrfwyb6o5tqid11gustz3uvy&dl=0 and let me know whether this fixes the problem. It should generate a driverWarning event but I haven't yet had time to set up a system to test it.

jjem

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

jay_s_uk

@jjem maybe adding segmentation, something like M669 S1 T1 will aid in being able to apply a speed change to the current move

jjem

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

jay_s_uk

@jjem it "may" affect IS but I'm not 100%. it shouldn't over power the MCU though

dc42

@jjem in general, moves already in the movement queue can't be altered. You can abort the later moves in the move queue by commanding a pause.

As @jay_s_uk says, you can use segmentation (see M669) to split long moves into short moves, to get faster response to movement speed changes and fast response to pause commands. To reduce movement speed temporarily I suggest you use M220 rather than M203.

jjem

@dc42 Thank you both.

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

gloomyandy

@jjem I think it would help if you posted an example and explained what you expect it to do and what you actually observe it doing.

jjem

@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

@jjem said in Configuring Pre-Stall:

@dc42 Thank you both.

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

It won't affect the speed of moves in system macros (e.g. homing, pausing) but it should affect speeds of moves in user macros - assuming that the requested speed wasn't higher than the limit set by M203.

jjem

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

jjem

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

@jjem you are right, currently M220 isn't applied to moves in macros at all. I'll look at how easily this can be fixed.

dc42

@jjem this should be fixed in the firmware I have just uploaded to https://www.dropbox.com/scl/fo/p0136wx04h8xf6ejwdnn9/h?rlkey=efrfwyb6o5tqid11gustz3uvy&dl=0.

jjem

@dc42 Great, thank you

jjem

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

dc42

@jjem I've just tested that macro, and with the new firmware build it works correctly for me when I invoke it directly from DWC.

jjem

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

droftarts

@jjem Do you mean your mainboard isn't updated? I think you're on a 6XD. Use Duet3Firmware_6XD.bin from @dc42's dropbox link above. It's there, I've checked!
For DWC, use "DuetWebControl-SD.zip" from https://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.0-rc.3

Ian

dc42

@jjem please post the output from sending M115 or M122, to confirm the firmware version you are using.

I tested the behaviour when running a macro directly from the Macros menu in DWC. It is likely to behave differently if the macro is called from a system macro such as pause.g.