Configuring Pre-Stall

jjem

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6XD version 3.5.0-rc.2 (2023-12-14 10:33:00) running on Duet 3 MB6XD v1.01 or later (standalone mode)
Board ID: 0JD2M-999AL-D25SW-6J1FD-3SJ6J-T4XH3
Used output buffers: 1 of 40 (22 max)
=== RTOS ===
Static ram: 153284
Dynamic ram: 117668 of which 0 recycled
Never used RAM 70056, free system stack 158 words
Tasks: NETWORK(1,ready,69.8%,175) ETHERNET(5,nWait,0.0%,317) HEAT(3,nWait,0.0%,359) Move(4,nWait,0.0%,216) CanReceiv(6,nWait,0.0%,797) CanSender(5,nWait,0.0%,329) CanClock(7,delaying,0.0%,350) MAIN(1,running,30.1%,444) IDLE(0,ready,0.0%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 02:59:59 ago, cause: software
Last software reset at 2024-02-20 08:45, reason: User, Gcodes spinning, available RAM 66000, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 39.9, current 41.8, max 41.9
Supply voltage: min 23.7, current 23.8, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.3, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 99/66, heap memory allocated/used/recyclable 4096/2332/184, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: ok
Driver 1: ok
Driver 2: ok
Driver 3: ok
Driver 4: ok
Driver 5: ok
Date/time: 2024-02-20 11:45:53
Slowest loop: 44.22ms; fastest: 0.07ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 3.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 3, maxWait 30055ms, bed compensation in use: none, height map offset 0.000, max steps late 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 9, completed 9, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP is ready with "m122 b0" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000007
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 54034, received 172846, lost 0, errs 0, boc 0
Longest wait 52ms for reply type 6041, peak Tx sync delay 272, free buffers 50 (min 49), ts 53996/53995/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 5.15ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 0 0 0 0
Socket states: 5 5 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

dc42

@jjem I think you are right: currently a pre-stall returns information in the driver status but does not appear to generate an event. I think our intention was to generate a driverWarning event, not a stall event. I will generate new 3.5.x EXP1HCL firmware to correct this.

jjem

@dc42 Good to know. That would be great, thank you. Do you know when that might be ready, so I can plan around it? Thanks.

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.