Posts made by hestiahuang

@oliof said in Issues with pressure advance since RRF 3.4:

@PCR so do I (actually capable of triple play -- Marlin, RRF, and Klipper). I can't say I have these issues with bulging corners but I run quite high extruder jerk and acceleration (https://forum.duet3d.com/topic/33964/e-acceleration-has-to-be-limited-to-to-e-jerk-pa?_=1700602309451). I wonder what e jerk and acceleration the people heavily affected run; if jerk and accel aren't high enough I can see that PA may kick in "late" and not have (any) effect, especially at higher speeds.

So first of all we need to stop tuninig anything but testing the capability of the E motor.
Btw, any steps or details shown how to find out the value?

@hestiahuang

Someone shared me that, he has the same issue on RRF, however It comes to be fixed after he using the Klipper. Really no idea what's the diff.

@hestiahuang

Adjust the belt tension can not fix the problem.

@hestiahuang

Most likely it is obvious on CoreXY machine. When there is a corner, and moving before arrived the end of corner, both A motor and B motor, need to slow down, severe bulging will come before arriving the corner. If it is the machine like UM, it will be only severe bulging after corner but never before corner, as there is only one aixs motor for each aixs. However this is the inherent feature for CoreXY, due to it needs both A motor an B motor keep moving.

This is the first time I am using CoreXY machine, the E3D ToolChanger.

No clue how to fix it...

What I guess, PA can't fix this, as it is XY movement related, not extrusion related. However the Input shaping is the direction. RRF Input shaping is still the blackbox, a long way need to go.

https://forum.duet3d.com/topic/33803/unable-to-stop-severe-bulging-in-corners-with-new-print-head/29

The same issue in above link too.

I have the same issue on ToolChanger machine too. I haven't found out the root cause yet.

so don't miss Duet2Wifi...

@hestiahuang said in 3.5 B3 Toolboard stepper intermittently running backwards:

@dc42 said in 3.5 B3 Toolboard stepper intermittently running backwards:

@ctilley79 you are correct, the P parameter doesn't work for Neopixels. I will correct this before we release beta4.

May I know how to define M950 for Duet2Wifi? It can use M150 directly before, however it is failed and need definition first now. But not pin name found...

Add the source code to confirm my finding.

@dc42 said in 3.5 B3 Toolboard stepper intermittently running backwards:

@ctilley79 you are correct, the P parameter doesn't work for Neopixels. I will correct this before we release beta4.

May I know how to define M950 for Duet2Wifi? It can use M150 directly before, however it is failed and need definition first now. But not pin name found...

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

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

thx for your help on that!

@dc42 great, thx!

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

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

@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

@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

@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

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

@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