RRF 3.4 input shaping preview available

[dc42]

@jenpet, input shaping may affect the behaviour of PA. When you test this 3.4beta with input shaping turned off, are the results similar to what you get using RRF 3.3 with DAA disabled, using the same PA ni both cases?

[JenPet]

@dc42 I dont know if the quality is equal to RRF 3.3.
I have tested different setting with input shaping an PA.
I tried different PA values, acceleration values, jerk values and speed values but I always get the issue on the picture.
But when I turn PA off, the issue is gone.

[dc42]

@jenpet can you tell me exactly where in that image the issue is?

Perhaps you are just using too much PA.

[JenPet]

@dc42 the two contour lines get thinner and thinner at the end so that there is a gap between them.
Now I try to lower PA value again.

[dc42]

@jenpet said in RRF 3.4 input shaping preview available:

@dc42 the two contour lines get thinner and thinner at the end so that there is a gap between them.
Now I try to lower PA value again.

If you mean the two perimeter lines, they are joined in the perimeter at the top, joined for part of the length of the perimeter on the right, and not joined at all in the perimeter at the bottom. The difference between top and bottom suggests to me that you have chosen an unfortunate wall thickness and the slicer has failed to ensure consistent infill by altering the extrusion widths - so that whether the perimeters are joined or not is very sensitive to small changes. I am assuming that the thickness of all three walls is supposed to be the same.

[CadetC]

@dc42 said in RRF 3.4 input shaping preview available:

@skrotz @jenpet I've put new binaries at https://www.dropbox.com/sh/ja08b7qdzsl8kjc/AAAwUbkN2XJvurq5CuQTgx5Wa?dl=0.

I just tested lates bin. - no clunking and nothing suspicious when printing
Test print done :speed 200mm/s, accel6000mm/s2 . PA 0.022
print sequence from bottom to top:
M593 P"none"
M593 P"ei2" F62.7
M593 P"ei3" F62.7
M593 P"zvdd" F62.7
M593 P"zvd" F62.7
I think best result with ei3 , second zvd.
First print where i could use zvd without any problems

There still problem with DSF compatibility(???)

Print status is 100% right away in DWC and PanelDue

[JenPet]

@dc42 I have lowered the PA value to 0.04 from 0.08 and now it looks better. I tried the same thing a few days ago but there was no inprovement. I think is was my mistake, sorry. Thank you for support.

[dc42]

@jenpet thanks. Your previous report was very useful because of the reported step errors, and led me to fix a bug.

[dc42]

@cadetc thanks. We are looking to release 3.4beta2 tomorrow, including the updated DSF.

[skrotz]

@dc42 I did a quick print with this latest firmware (PA 0.12, ei2 input shaping enabled as per usual) and can't say I see a significant difference between this firmware and the previous one on my print, although I'd swear that the previous one still had a tiny bit of "clunkiness" and this one seemed completely normal with no hint of a clunk whatsoever. No hiccups or errors in the M122 report. Like the just previous firmware, I don't see extrusion blobs or zits like were happening before -- I'll need to do some comparison prints with RRF 3.3 and this firmware to see if the minor extrusion issues I feel are present are different from RRF 3.3 or not. All in all, great progress though, and certainly seems ready for more people to start doing prints and comparisons with RRF 3.3 and testing input shaping. Very exciting.

RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta2-inputshaping (2021-08-02 19:33:23) running on Duet WiFi 1.02 or later + DueX5

UPDATE: I did a baseline print with RRF 3.3 to compare with (DAA enabled at 41hz, PA 0.12), and the minor extrusion issues I was seeing in the latest 3.4 print are there as well in the 3.3 print.. it seems like something that could be improved on but it's not introduced by 3.4. So this latest 3.4 seems quite good to go.

[MikeS]

@dc42 thanks for the new release. It seems that is running good, you should call the next beta "clunk free".

However i noticed i can't stop during mid-print because the firmware goes to status "generic.status.cancelling" when cancel button is pressed. From there i can't press the cancel anymore and the printer won't start a new job

M122

3/8/2021, 19:41:13 	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta2-inputshaping (2021-08-02 19:33:23) running on Duet WiFi 1.02 or later + DueX5
Board ID: 0JD0M-9P61A-J8PS8-6JTD2-3SJ6R-9USUU
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 23932
Dynamic ram: 76624 of which 188 recycled
Never used RAM 7376, free system stack 106 words
Tasks: NETWORK(ready,14.1%,217) HEAT(delaying,0.0%,326) Move(notifyWait,1.2%,277) DUEX(notifyWait,0.0%,24) MAIN(running,84.5%,420) IDLE(ready,0.1%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:25:32 ago, cause: software
Last software reset at 2021-08-03 19:15, reason: User, GCodes spinning, available RAM 7376, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 39.5, current 40.2, max 40.7
Supply voltage: min 23.6, current 23.8, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/886/886, gc cycles 0
Driver 0: position 28800, standstill, SG min/max 0/1023
Driver 1: position -27200, standstill, SG min/max 0/1023
Driver 2: position 13510, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max 0/1023
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0, standstill, SG min/max 0/1023
Driver 6: position 0, standstill, SG min/max 0/248
Driver 7: position 0, standstill, SG min/max 0/1023
Driver 8: position 0, standstill, SG min/max 0/1023
Driver 9: position 0, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-08-03 19:41:13
Cache data hit count 4294967295
Slowest loop: 191.24ms; 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 1.8ms, write time 5.4ms, max retries 0
=== Move ===
DMs created 83, segments created 46, maxWait 15496ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 10346, completed moves 10346, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 2], 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 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.5
=== 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== DueX ===
Read count 1, 0.04 reads/min
=== Network ===
Slowest loop: 209.69ms; fastest: 0.00ms
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 0
WiFi firmware version 1.24
WiFi MAC address 48:3f:da:79:65:eb
WiFi Vcc 3.34, reset reason Power up
WiFi flash size 4194304, free heap 27144
WiFi IP address 192.168.1.230
WiFi signal strength -23dBm, mode none, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

[dc42]

@mikes, that bug was fixed in the 3.4.0 beta 2 release.

[MikeS]

@dc42 i lost one day and the beta is already out! thank you!

[dc42]

I wish to thank all who have tested the RRF input shaping previews. With your help, I believe I have the new step generation code working well including input shaping and pressure advance. This has given me the confidence to include the new code in RRF 3.4.0 beta 2 which we released today.

Please upgrade to that release, and start new threads for any issues you encounter with it.

[Egon.Net]

@dc42 said in RRF 3.4 input shaping preview available:

@jenpet said in RRF 3.4 input shaping preview available:

@dc42 the two contour lines get thinner and thinner at the end so that there is a gap between them.
Now I try to lower PA value again.

If you mean the two perimeter lines, they are joined in the perimeter at the top, joined for part of the length of the perimeter on the right, and not joined at all in the perimeter at the bottom. The difference between top and bottom suggests to me that you have chosen an unfortunate wall thickness and the slicer has failed to ensure consistent infill by altering the extrusion widths - so that whether the perimeters are joined or not is very sensitive to small changes. I am assuming that the thickness of all three walls is supposed to be the same.

I also have problems with pressure advance and input shaping with de PA values I already got finetuned without input shaping.

Top one: input shapping ei3 @48Hz + PA 0.1 (orbiter extruder direct)

Bottom one: just input shapping and no PA

Both 100mm/sec, 6000mm/s2 acceleration

You can see corners are ok with the PA, and bulges with no PA...