Issues with pressure advance since RRF 3.4

dc42

@argo thanks for reporting this. The implementation of PA had to be largely rewritten in RRF 3.4, so a bug may have crept in.

You said that for you, the problem started at RRF 3.4beta7. Can you remember what was the last RRF 3.4beta you installed that did not have the problem - was it beta6, or an earlier one?

Argo

@dc42

I just flashed RRF 3.4 beta 2 as this is the first beta that mentions input shaping and I assume PA has been rewritten for input shaping.

Here is the result. PLA, direct extruder (Bondtech LGX) and PA value of 0.068 which is already too high for direct extruder printing PLA in my opinion as you can see in the example below, the infill line is too thin at the end. But the corners are still bulging. It almost looks like PA isn't applied at all for corners compared to RRF 3.3.
Input shaping was off (for all tests in this thread).

photo_2022-07-07 16.25.30.jpeg

M122 right after the test print:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.4.0beta2 (2021-08-03 12:43:05) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: W0DS5-R296U-D65J0-40KM6-LU03Z-Z3F72
Used output buffers: 6 of 40 (40 max)
=== RTOS ===
Static ram: 102724
Dynamic ram: 107996 of which 16 recycled
Never used RAM 27832, free system stack 118 words
Tasks: NETWORK(ready,10.6%,214) HEAT(delaying,0.0%,343) Move(notifyWait,0.0%,255) CanReceiv(notifyWait,0.0%,773) CanSender(notifyWait,0.0%,369) CanClock(delaying,0.0%,347) TMC(delaying,1.2%,72) MAIN(running,87.3%,432) IDLE(ready,0.0%,29) AIN(delaying,0.8%,264), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:27:44 ago, cause: power up
Last software reset at 2022-07-07 15:54, reason: User, GCodes spinning, available RAM 31492, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 1664433, completed 1664432, timed out 0, errs 0
Step timer max interval 725
MCU temperature: min 39.3, current 39.3, max 39.6
Supply voltage: min 24.4, current 24.5, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/144/132, gc cycles 0
Driver 0: position 90080, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 54, writes 0, timeouts 0, DMA errors 0
Driver 1: position 1120, standstill, SG min/max 2/2, read errors 0, write errors 0, ifcnt 27, reads 54, writes 0, timeouts 0, DMA errors 0
Driver 2: position 16852, standstill, SG min/max 2/2, read errors 0, write errors 0, ifcnt 27, reads 54, writes 0, timeouts 0, DMA errors 0
Driver 3: position 0, standstill, SG min/max 2/2, read errors 0, write errors 0, ifcnt 28, reads 54, writes 0, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 27, reads 54, writes 0, timeouts 0, DMA errors 0
Driver 5: position 0, standstill, SG min/max 2/2, read errors 0, write errors 0, ifcnt 27, reads 54, writes 0, timeouts 0, DMA errors 0
Driver 6: position 0, standstill, SG min/max 2/2, read errors 0, write errors 0, ifcnt 27, reads 54, writes 0, timeouts 0, DMA errors 0
Date/time: 2022-07-07 16:27:48
Cache data hit count 3022789118
Slowest loop: 3.08ms; fastest: 0.12ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 12, maxWait 0ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 3313, completed moves 3313, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock 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
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
Code queue is empty
=== Filament sensors ===
Extruder 0: no data received
=== CAN ===
Messages queued 5, received 6, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 3, free buffers 17 (min 17), ts 3/3/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 201.07ms; fastest: 0.06ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 19
WiFi firmware version 1.26
WiFi MAC address f0:08:d1:02:e7:b3
WiFi Vcc 3.36, reset reason Power up
WiFi flash size 2097152, free heap 24936
WiFi IP address 192.168.1.120
WiFi signal strength -72dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

Duet 1LC:

M122 B121
Diagnostics for board 121:
Duet TOOL1LC firmware version 3.4.0beta2 (2021-08-03 10:00:09)
Bootloader ID: SAMC21 bootloader version 2.3 (2021-01-26b1)
Never used RAM 2204, free system stack 2719 words
Tasks: Move(notifyWait,0.0%,99) HEAT(delaying,0.2%,105) CanAsync(notifyWait,0.0%,57) CanRecv(notifyWait,0.1%,74) CanClock(notifyWait,0.0%,65) ACCEL(notifyWait,0.0%,61) TMC(delaying,2.8%,57) MAIN(running,91.9%,352) IDLE(ready,0.0%,27) AIN(delaying,4.9%,142), total 100.0%
Last reset 00:27:40 ago, cause: power up
Last software reset time unknown, reason: AssertionFailed, available RAM 3392, slot 0
Software reset code 0x0120 ICSR 0x00000000 SP 0x2000415c Task  Freestk 129 bad marker
Stack: 00000544 00022ffc 00019b65 20003134 00016cff 20003134 000163d1 20000ed0 00000000 00000001 00008275 200071c8 200071c8 200071e0 00000000 20000f50 00011647 000223b8 00022474 00021ac8 00019b05 200071c8 200071c8 20000f50 000083ed 200071d8 000009c7
Driver 0: position 500392, 400.0 steps/mm, standstill, SG min/max 2/2, read errors 0, write errors 0, ifcnt 13, reads 386, writes 0, timeouts 0, DMA errors 0, steps req 0 done 0
Moves scheduled 2364, completed 2364, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -1/4, peak Rx sync delay 183, resyncs 0/0, no step interrupt scheduled
VIN: 24.2V
MCU temperature: min 34.4C, current 46.0C, max 46.6C
Ticks since heat task active 49, ADC conversions started 1659491, completed 1659489, timed out 0, errs 0
Last sensors broadcast 0x00000002 found 1 54 ticks ago, loop time 0
CAN messages queued 47, send timeouts 0, received 15, lost 0, free buffers 37, min 37, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer detected: yes, status: 00
I2C bus errors 0, naks 0, other errors 0
=== Filament sensors ===
Interrupt 4 to 8us, poll 9 to 177us
Driver 0: pos 339.61, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0

Tinchus

I will add a little comment here based on my past experience tunning PA: it works very well whilw the requested speed ks close to the real speed. The further you go and the results starts to be less effective. In yor slicer config i can see a perimeter speed of 120mm s, and your infill has 260 mm s. In your pictures i see what it looks like a test cube .
If that cube is small, you will never reach 120, that would be the requested speed. Firmware will give so ething smaller.
But later in tbe infill the requested 260 speed will never be reached either but the difference between requeste and real speed will be muuuuuch bigger, so probably you wont bave very good results.
I would suggest to retune PA with a model that let you reach real values closer to the requested speed and retest to see if there is any difference

jackantubis

I have same kind of issues since 3.4.
Maybe the Pressure Advance don't have a 3rd order compensation for speed variation, could be a good update.
Made 4 measurements at different speed, make the equation in excel.
Can we add this with "Duet programming Gcode" ?

Argo

@tinchus

Thanks for your theory but requested speeds are reached.

CCS86

This is very interesting. I had noticed some of these artifacts too but hadn't pinned it down to PA changes in the 3.4 releases. Good job zeroing in on this!

gnydick

same experience, lurking for update

CCS86

Well, that sucked... I tried to downgrade to 3.3 for a back to back print test and that almost destroyed my Mosquito hot end. The hot end fan spooled up with its normal blip, but then slowly wound down to zero at my normal PWM setting. The entire heat sink ended up packed with molten filament and had to be drilled out. The hot end fan won't stay running at any other PWM value than 255.

Off topic, but what changed between 3.3 and 3.4 on this? I'm back on 3.4 and it runs fine again.

Phaedrux

@ccs86 How did you have it configured?

When a fan is configured as thermostatic using M106, the S parameter is now ignored. If a single T value is given, then when the temperature is above the T parameter the fan will run at the PWM specified by the X (maximum PWM) parameter (default 1.0).

From the 3.4 notes.

Argo

@jackantubis @gnydick @CCS86

Could you also please provide some examples? So we can be sure we are having the same issue.

gnydick

@argo https://forum.duet3d.com/post/289116

jumpedwithbothfeet

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

@ccs86 How did you have it configured?

When a fan is configured as thermostatic using M106, the S parameter is now ignored. If a single T value is given, then when the temperature is above the T parameter the fan will run at the PWM specified by the X (maximum PWM) parameter (default 1.0).

From the 3.4 notes.

Apologies for going off topic, but by that statement M106 in GCode dictionary could very much do with a rewrite

gloomyandy

@gnydick Can I just check, I think in the your other thread you reported that going back to 3.3 did not make any difference to the results you are seeing? Is that correct or was the regression test you did just to 3.4?

Argo

@dc42
Have you already had time to look into this or can I provide you with more data/examples...?

Argo

@paanjii2

All details are in this thread and in this one: https://forum.duet3d.com/topic/26062/3-4-0beta7-new-input-shaper-disturb-pressure-advance

If you want any specific information please ask.

gnydick

@gloomyandy that is correct, didn't see a difference.

dc42

@argo this is close to the top of my list to look into. What's a good print to test this on - is a hollow square tube sufficient?

Argo

@dc42

You could just create a shape box in Prusa Slicer (or similar slicer that can generate shapes) with the following measurements:

X: 50mm
y: 20mm
Z: 5mm

Perimeters: 3
Top Layer: 0
Bottom Layer: 4
Infill: Grid 20%
Layer time goal: 0s (so it does not slow down the print)

My speed settings: https://forum.duet3d.com/post/288649

If you are using a direct drive extruder with PLA a PA value around 0.055 is usually a good value.
I would not print it hollow so you can compare the quality of infill lines and corners.
The issue I'm having is healthy infill lines and bulging corners or sharp(ish) corners but starving infill lines (example in this posting: https://forum.duet3d.com/post/288686).

dc42

I confirm there is an issue with pressure advance in RRF 3.4. It works better in 3.3 but I think it is still not quite right. We'll issue another 3.4.2rc release when we have fixed it.

dc42

Further to my previous message: I made a mistake in my test program. Currently I can't see any difference in how PA behaves between 3.3 and 3.4 with input shaping disabled. I will investigate further next week.