M915 feature is loss after 3.5.0 beta2 version on extruder

[hestiahuang]

@dc42 , I upgraded the duet2wifi firmware to 3.5.0 beta2 version serial days ago. And I found the motor stall detection on extruders feature doesn't work now. It is working fine on 3.4 release version.

Background
I am using bowden extruder and need motor stall detection on extruders. So it can stop extrusion automactically, no exact length calculation.

Simulation Steps
1. config the threshold(no mater high/low all failed, [Lower values make stall detection more sensitive, -63-63]) => M915 P4 S10 F0 R0
2. Set extruder stall detection current(no mater high/low all failed, 30-100]) => M913 E30
3. Try extrude but no response on extruder(However this line can extrude -> G1 E200 F1500, which is without H1) => G1 H1 E200 F1500

H1 can be used for extruder b4, would you please have a check? No everyone is using the direct driver extruder, really need this feature back. Thanks.

[Phaedrux]

Are you using cold extrusion for this?

[chrishamm]

@hestiahuang I use this feature on 3.5-b3 and it works. Please update to v3.5-b3 as well and check if the problem persists.

[hestiahuang]

@Phaedrux said in M915 feature is loss after 3.5.0 beta2 version on extruder:

Are you using cold extrusion for this?

haha, it is normal PLA temperature, 210°c

[hestiahuang]

@chrishamm said in M915 feature is loss after 3.5.0 beta2 version on extruder:

@hestiahuang I use this feature on 3.5-b3 and it works. Please update to v3.5-b3 as well and check if the problem persists.

Should I disable PA first?

[chrishamm]

@hestiahuang Have you upgraded to 3.5-b3 and checked if the problem remains?

[hestiahuang]

@chrishamm said in M915 feature is loss after 3.5.0 beta2 version on extruder:

@hestiahuang I use this feature on 3.5-b3 and it works. Please update to v3.5-b3 as well and check if the problem persists.

@dc42

I am using 3.5 b3 now. However the result is negative.
I can confirm it is a firmware upgrade issue, base on the finding below. So I guess there are some mix-up codes between laser mode and move type.
1. It is working fine if I am using “G1 S1 E200 F1500”. But there is no extrusion while I am using “H1” parameter.
2. Double check on WIKI and we expect that "S" will be reserved to laser mode, and "H" is for move type. So this is the conflict point.

//Quoted from WIKI
Hnnn Move type (RRF2.02 and later, RRF3)
Snnn In RRF3, this parameter is used to set laser power, when switched into Laser mode (see M452); its use for defining move type is deprecated, use 'H' parameter instead. In RRF2.02 and later, when switched into Laser mode (see M452), this parameter sets the laser power. When not switched into Laser mode, and always in firmware 2.01 and earlier, it defines the move type (see the description of the H parameter).
//Unquoted

[chrishamm]

@hestiahuang Interesting, thanks. I'll investigate.

[chrishamm]

@hestiahuang I've checked the underlying code and there is no notable difference between the code used on the Duet 2 and 3. G1 S is only supported in Laser mode and the S parameter is ignored otherwise in 3.5-b3. Only G1 H1 moves can use SG for filament loading. If you are still on an old RRF version, this behaviour may be inverted, i.e. G1 S1 stops when the extruder stalls and G1 H1 acts like a normal move without SG detection.

Please send the output of M122 from your machine.

[dc42]

@hestiahuang here are two possible explanations:

1. G1 H1 moves involving stall detection use the M201.1 acceleration parameters instead of the M201 acceleration parameters. Send M201.1 to see what they are set to. You may need to use M201.1 in config.g to set lower values, if the acceleration used is so high that the extruder motor stalls immediately because of the motor inertia.

2. It can sometimes be the case that a driver reports a stall from a previous move. The workaround is to command a short move with stall detection not operating. The short move needs to be at least one full step in length. For example, use a normal G1 move to extrude 1mm of filament before you do the G1 H1 move.

[hestiahuang]

@chrishamm I am not sure why, maybe H1 is never been tested for ST yet. However the restult is as my test reported.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-beta.3 (2023-04-14 11:27:37) running on Duet WiFi 1.02 or later + DueX5
Board ID: 0JD0M-9P6M2-NW4SD-6JKFG-3SJ6S-KAQBJ
Used output buffers: 2 of 26 (26 max)
=== RTOS ===
Static ram: 22192
Dynamic ram: 84248 of which 0 recycled
Never used RAM 8, free system stack 112 words
Tasks: NETWORK(ready,810.1%,194) HEAT(nWait,6.3%,307) Move(nWait,25.0%,291) DUEX(nWait,0.0%,26) MAIN(running,75.6%,451) IDLE(ready,1.2%,29), total 918.3%
Owned mutexes:
=== Platform ===
Last reset 09:03:48 ago, cause: software
Last software reset at 2023-04-23 10:51, reason: StuckInSpinLoop, Gcodes spinning, available RAM 1100, slot 2
Software reset code 0x4083 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x200021f8 Task NETW Freestk 4294966881 ok
Stack: 00000000 200012dc 10000000 e000e000 000000a0 0045f78b 0045ef00 610b0000 0045eef1 00000000 ffffffff 00000000 050a5a26 00000000 20000d94 ffffffff 20002818 200194e8 0045efb7 200002e0 200022cc 200194e8 0045c3f7 20000d94 00405a29 20000b58 0042d70f
Error status: 0x04
Aux0 errors 0,0,0
MCU temperature: min 35.1, current 35.8, max 49.7
Supply voltage: min 22.4, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 198/85, heap memory allocated/used/recyclable 4096/3360/1644, gc cycles 1
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: standstill, SG min n/a
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min 0
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
Date/time: 2023-04-23 19:55:46
Cache data hit count 4294967295
Slowest loop: 238.91ms; fastest: 0.14ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 10.9ms, write time 2.8ms, max retries 0
=== Move ===
DMs created 83, segments created 41, maxWait 624886ms, bed compensation in use: none, comp offset 0.000
no step interrupt scheduled
=== DDARing 0 ===
Scheduled moves 85286, completed 85286, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.1
=== GCodes ===
Movement locks held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== DueX ===
Read count 301, 0.55 reads/min
=== Network ===
Slowest loop: 210.71ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Network state is active
Module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
Firmware version 2.1beta4
MAC address e8:db:84:9b:18:c5
Module reset reason: Power up, Vcc 3.36, flash size 2097152, free heap 42856
WiFi IP address 192.168.50.52
Signal strength -50dBm, channel 7, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

[hestiahuang]

@chrishamm said in M915 feature is loss after 3.5.0 beta2 version on extruder:

@hestiahuang I've checked the underlying code and there is no notable difference between the code used on the Duet 2 and 3. G1 S is only supported in Laser mode and the S parameter is ignored otherwise in 3.5-b3. Only G1 H1 moves can use SG for filament loading. If you are still on an old RRF version, this behaviour may be inverted, i.e. G1 S1 stops when the extruder stalls and G1 H1 acts like a normal move without SG detection.

Please send the output of M122 from your machine.

Let me try explain more what my config.

1. The whole macro can run fine after I change "H" back to "S". No other extra change.
2. code like this

M201 E10000
M915 P3 S6 F0 R0
G1 E-1 F300
G1 E60 F300
G1 E800 F4800
M201 E1000
M913 E28
G1 S1 E200 F1500
M915 P3 R0
M913 E100
M201 E10000

[hestiahuang]

@dc42

I really not config the M201.1 in my config.g. I guess it is defaul by the firmware. My machine is E3D ToolChanger.
Simulation steps like my macro code about.

1. M201 to set the acceleration to 10000
2. Define the ST
3. Retract 1mm avoid to trigger ST detection
4. Run extrusion and load the filament slowly
5. Load filament fast
6. M201 to change the acceleration to 1000
7. Change ST detection current to 28%(full current is 1250mA)
8. G1 S1 E200 F1500 => Extrude 200mm with 25mm/s, ensure it ST can be captured(Howere there is no move if it is H1, it is working fine it is S1)
9. Turn off ST
10. Resume 100% current
11. Set the acceleration back to 10000

[dc42]

@hestiahuang on a G1 H1 move with a stall endstop enabled, the M201.1 acceleration is used instead of the M201 acceleration. So try removing the M201 commands from your macro and instead adding M201.1 E1000 to your config.g file or to that macro.

[hestiahuang]

@dc42 said in M915 feature is loss after 3.5.0 beta2 version on extruder:

@hestiahuang on a G1 H1 move with a stall endstop enabled, the M201.1 acceleration is used instead of the M201 acceleration. So try removing the M201 commands from your macro and instead adding M201.1 E1000 to your config.g file or to that macro.

Noted and thx, I can't wait to try now.

[hestiahuang]

@dc42 said in M915 feature is loss after 3.5.0 beta2 version on extruder:

@hestiahuang on a G1 H1 move with a stall endstop enabled, the M201.1 acceleration is used instead of the M201 acceleration. So try removing the M201 commands from your macro and instead adding M201.1 E1000 to your config.g file or to that macro.

Just tried. Result is the same as before.

```
M915 P3 S6 F0 R0 ;Define the ST
G1 E-1 F300 ;Retract 1mm avoid to trigger ST detection
G1 E60 F300 ;Run extrusion and load the filament slowly
G1 E800 F4800 ;Load filament fast
M201.1 E1000 ;M201.1 to define the acceleration to 1000
M913 E28 ;Change ST detection current to 28%(full current is 1250mA)
G1 H1 E200 F1500 ;Extrude 200mm with 25mm/s ====>tested and found there is no move(no extrusion)
M915 P3 R0 ;Turn off ST
M913 E100 ;Resume 100% current

[hestiahuang]

What my point is if the same macro, and the change is only from S1 to H1 and M201 to M201.1, why it is not working now. What change else I should implement?

[dc42]

@hestiahuang only two of us at Duet3D have Duet 2 systems that could be used to try to reproduce the issue you are experiencing, and both of us are away at present. I will be back next week so I will try to reproduce it then.

[hestiahuang]

@dc42 great, thx!

[dc42]

@hestiahuang I raised this issue https://github.com/Duet3D/RepRapFirmware/issues/847

dc42 created this issue in Duet3D/RepRapFirmware

closed G1 H1 E moves not working in 3.5.0-beta.3 #847