RRF 3.4 input shaping preview available

skrotz

@dc42 Can confirm some weirdness. Was running RRF 3.3 release, uploaded new 3.4 combined firmware to duet2 wifi on a Railcore 300ZL. It reset itself after upload and homing and movement seemed ok, but when actually trying to print it seemed to stall or something, with occasional random movements.

I powered off and on and disabled all input shaping (it still had DAA enabled from my default setup, at 40hz). Was able to print a calibration cube after that, don't know if it was disabling the input shaping that did it or the power cycle. However, when printing the gyroid infill it would make a weird clunking noise that I couldn't identify where/what was happening exactly. Cube printed roughly ok however, but somewhat under extruded so maybe it was extruder motor making the clunking.

Just to be sure, I went back to R3.3 stock and things seem to be printing ok again, no clunk noises, on same exact gcode, so definitely looks like it was 3.4 causing some strangeness.

update: R3.3 calibration cube printed normally, and didn't have any underextrusion issues (or at least, something that looked like underextrusion).

Nuramori

@dc42 Yes, which works very well.

sebkritikel

@dc42 When sending commands via the console on Safari (iPhone), the print freezes, and the console returns the following:

M593 P"zvd" F30
Error: M593: expected string expression

Sending the same command from my PC (Firefox) results in the command being applied, and the print immediately resuming.

Steps I took prior to upgrading from 3.3 stable

Disabled mesh compensation
Disabled pressure advance
Disabled any M593 settings

I had no issues uploading the 3.4 .bin, homing, or starting the baseline print.

A few (ugly) pictures of the results - images showing the ringing are all from the same side, just focusing the camera on the spots indicated in blue boxes. ZVD worked great, ZVDD, EI2, EI3 drifted along the positive X and negative Y directions. IDEX printer, printed with only T0. No pressure advance.

M122 taken near the end of the print:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0-inputshaping (2021-07-09 09:08:54) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917DA-G4MSD-6JTDD-3SN6L-1STR9
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 23932
Dynamic ram: 79136 of which 176 recycled
Never used RAM 7876, free system stack 112 words
Tasks: NETWORK(ready,15.3%,219) ACCEL(notifyWait,0.0%,348) HEAT(delaying,0.0%,326) Move(notifyWait,0.2%,285) DUEX(notifyWait,0.0%,24) MAIN(running,84.4%,449) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:32:53 ago, cause: software
Last software reset at 2021-07-09 19:52, reason: User, GCodes spinning, available RAM 11468, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x16
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 34.7, current 36.0, max 36.3
Supply voltage: min 23.8, current 23.9, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 2800, ok, SG min/max 0/1023
Driver 1: position -5757, ok, SG min/max 0/1023
Driver 2: position 42880, standstill, SG min/max 0/235
Driver 3: position 26700, ok, SG min/max 0/1023
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0, standstill, SG min/max not available
Driver 6: position 0, standstill, SG min/max not available
Driver 7: position 0, standstill, SG min/max not available
Driver 8: position 0, standstill, SG min/max not available
Driver 9: position 0, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-07-09 20:53:15
Cache data hit count 4294967295
Slowest loop: 9.31ms; fastest: 0.10ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.3ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 40, maxWait 85735ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 7108, completed moves 7096, hiccups 0, stepErrors 34, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== 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.5
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X-53.5 Y-1.02 E0.10461" 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 0, 0.00 reads/min
=== Network ===
Slowest loop: 201.69ms; fastest: 0.09ms
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 2
WiFi firmware version 1.23
WiFi MAC address cc:50:e3:0d:25:4b
WiFi Vcc 3.40, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24120
WiFi IP address 192.168.0.8
WiFi signal strength -44dBm, mode none, reconnections 0, sleep mode modem
Clock register ffffffff
Socket states: 0 0 0 0 0 0 0 0

dc42

Those of you having issues with these binaries (e.g. clunking or layer shifts), please attach a laptop via USB, load a terminal emulator, and send M111 P4 S1 to enable debug output from the Move module. If during a print it starts outputting DDA and DM listings in that terminal, then please share a sample of that output, your config.g file, and the print file.

If you can't easy attach a laptop, I am still interested in having your print file and config.g if a subsequent M122 report shows step errors is the MainDDARing section.

dc42

@sebkritikel your M122 file shows some step errors. Please share the print file and config.g.

I suspect that your iPhone was sending the wrong type of double quote characters.

dc42

I've just found that one of my other prints is also giving step errors. I'll try to squeeze a fix in this weekend. Until I have a fix, I suggest other users hold off from from using this firmware.

dc42

I have now updated the binaries at https://www.dropbox.com/sh/l020weqx7pijv84/AACFM3knhVXQ1hKu6NyKOfx6a?dl=0. These fix the bug that gave step errors when running one of my tests prints, so they may well fix the main issues that other users found when using the binaries that I posted yesterday. I also found and fixed a less serious bug that sometimes caused an incorrect amount of extruder retraction at the end of a move, when medium to large values of pressure advance were used.

skrotz

@dc42 Tried the new firmware, did a full power cycle after installing just in case. Had same clunking noise on printing a calibration cube on the infill. I discovered disabling pressure advance caused it to stop clunking.

Normally I have S 0.12 for PA, with a little experimentation anything at 0.4 or above (ish) seems to cause the clunking noise. If there's specific debug that would help with this, I can try and gather it.

dc42

@skrotz thanks. I've only tried pressure advance up to 0.2. It sounds like I have a little more work to do to get it right.

After you have run a print with high PA and had the clunking, does M122 report any step errors in the MainDDARing debug?

dc42

@skrotz PS - is your extruder drive connected to the main board, or to a CAN-connected expansion or tool board?

dc42

Last update for tonight. I've updated the binaries at https://www.dropbox.com/sh/l020weqx7pijv84/AACFM3knhVXQ1hKu6NyKOfx6a?dl=0 once more:

These binaries are based on RRF 3.4.0beta1. This means that if you want use them with attached SBC, you must first upgrade to 3.4.0beta1 from the unstable feed on the package server; and then upgrade to the input shaping RRF binary. The benefit is that you will be able to collect data from an accelerometer if you have one. If necessary you can downgrade later to the standard RRF 3.4.0beta1 binary from https://github.com/Duet3D/RepRapFirmware/releases/tag/3.4.0beta1.
I fixed a bug that caused extrusion to be inaccurate when the extruder was driven from a CAN-connected tool or expansion board.

sebkritikel

@dc42 said in RRF 3.4 input shaping preview available:

Last update for tonight. I've updated the binaries at https://www.dropbox.com/sh/l020weqx7pijv84/AACFM3knhVXQ1hKu6NyKOfx6a?dl=0 once more:

These binaries are based on RRF 3.4.0beta1. This means that if you want use them with attached SBC, you must first upgrade to 3.4.0beta1 from the unstable feed on the package server; and then upgrade to the input shaping RRF binary. The benefit is that you will be able to collect data from an accelerometer if you have one. If necessary you can downgrade later to the standard RRF 3.4.0beta1 binary from https://github.com/Duet3D/RepRapFirmware/releases/tag/3.4.0beta1.

I fixed a bug that caused extrusion to be inaccurate when the extruder was driven from a CAN-connected tool or expansion board.

You're too quick on the updates!

Was testing your previous update,'none', 'zvd', 'zvdd', 'EI2', and 'EI3' all work as expected. 'daa' does some wonky movement - unfortunately I mistakenly cleared out the terminal logs, so I'll retest 'daa' on your newest version hopefully sometime soon.

dc42

@sebkritikel thanks for testing it. DAA uses a different section of code from the other methods, so it could quite easily have different bugs. I'll quite likely remove support for DAA if the other methods turn out to be better, as I expect.

OwenD

@dc42 So far I have found as soon as DAA is enabled I get a massive layer shift and it stops extruding.
Currently testing other modes as I had DAA first.'

Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.4.0beta1-inputshaping (2021-07-10)
Duet WiFi Server Version: 1.26

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta1-inputshaping (2021-07-10 20:57:53) running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F2MS4-7J1DA-3S86T-TZTWD
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 23932
Dynamic ram: 79088 of which 208 recycled
Never used RAM 5684, free system stack 112 words
Tasks: NETWORK(ready,24.2%,237) ACCEL(notifyWait,0.0%,348) HEAT(delaying,0.0%,326) Move(notifyWait,0.1%,283) MAIN(running,69.0%,420) IDLE(ready,6.6%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 01:27:13 ago, cause: software
Last software reset at 2021-07-10 20:15, reason: User, GCodes spinning, available RAM 8456, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x0e
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 17.8, current 18.1, max 18.6
Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/16, heap memory allocated/used/recyclable 2048/2032/1806, gc cycles 9
Driver 0: position 2996, standstill, SG min/max not available
Driver 1: position 3081, standstill, SG min/max 0/555
Driver 2: position 14, standstill, SG min/max 0/130
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max 0/160
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-07-11 09:22:19
Cache data hit count 4294967295
Slowest loop: 8.78ms; fastest: 0.12ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 1.7ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 13, maxWait 91990ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 199, completed moves 196, hiccups 5, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== 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.3
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X151.413 Y31.057 E0.04606" 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 0, running macro
Autopause is idle in state(s) 0
Code queue is empty.
=== Filament sensors ===
Extruder 0 sensor: ok
=== Network ===
Slowest loop: 201.15ms; fastest: 0.09ms
Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(1), 1 sessions
HTTP sessions: 2 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 3
WiFi firmware version 1.26
WiFi MAC address bc:dd:c2:89:a0:bb
WiFi Vcc 3.37, reset reason Power up
WiFi flash size 4194304, free heap 22112
WiFi IP address 192.168.1.163
WiFi signal strength -61dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 2 0 4 4 0 0 0 0

OwenD

Can confirm all other input shaping modes worked but daa causes step loss every time.
Also stops extruding for some reason.
M122 after canceling

11/07/2021, 1:27:54 pm	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta1-inputshaping (2021-07-10 20:57:53) running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F2MS4-7J1DA-3S86T-TZTWD
Used output buffers: 4 of 24 (24 max)
=== RTOS ===
Static ram: 23932
Dynamic ram: 79088 of which 16 recycled
Never used RAM 5156, free system stack 108 words
Tasks: NETWORK(ready,168.2%,229) ACCEL(notifyWait,0.0%,348) HEAT(delaying,0.3%,326) Move(notifyWait,1.0%,299) MAIN(running,220.9%,420) IDLE(ready,61.3%,29), total 451.7%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 02:54:25 ago, cause: power up
Last software reset at 2021-07-11 09:24, reason: User, GCodes spinning, available RAM 5684, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x0e
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 16.7, current 24.0, max 26.3
Supply voltage: min 24.1, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/16, heap memory allocated/used/recyclable 2048/1656/1430, gc cycles 17
Driver 0: position 0, standstill, SG min/max 0/582
Driver 1: position 20000, standstill, SG min/max 0/1023
Driver 2: position 24864, standstill, SG min/max 0/648
Driver 3: position 0, standstill, SG min/max 0/1023
Driver 4: position 0, standstill, SG min/max 0/1023
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-07-11 13:27:49
Cache data hit count 4294967295
Slowest loop: 318.94ms; fastest: 0.12ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 2.3ms, write time 91.9ms, max retries 0
=== Move ===
DMs created 83, segments created 43, maxWait 158450ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 28342, completed moves 28342, hiccups 0, stepErrors 5, LaErrors 0, Underruns [0, 0, 3], 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
=== 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 0, running macro
Autopause is idle in state(s) 0
Code queue is empn 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 0, running macro
Autopause is idle in state(s) 0
Code queue is empty.
=== Filament sensors ===
Extruder 0 sensor: ok
=== Network =essions: 2 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.26
WiFi MAC address bc:dd:c2:89:a0:bb
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 23688
WiFi IP address 192.168.1.163
WiFi signal strength -65dBm, mode 802.11n, reconnections 0, sleep mo

dc42

@owend I confirm there is a bug in the implementation of DAA. I hope to get time to fix it today.

dc42

I have updated the binaries at https://www.dropbox.com/sh/l020weqx7pijv84/AACFM3knhVXQ1hKu6NyKOfx6a?dl=0 again:

Fixed a bug that caused incorrect movements when DAA input shaping was selected
Fixed a bug that sometimes caused incorrect extrusion on CAN-connected extruders when pressure advance was used
Fixed a bug that caused a filament error pause to lock up if the pause.g file used certain commands in combination, e.g. a M106 command followed by a tool change
Increased Duet 3 MB6HC Ethernet task stack size by 50 words
Fixed a bug that caused a crash when the slicer labeled objects using M486 and there were more than 20 (Duet 2) or 40 (Duet 3) objects on the build plate. Unlike the other ones, this bug is also present in RRF 3.3 stable and 3.4.0beta1.

I have tested that movement with DAA enabled is now working; however on my delta printer, when printing the test piece it's much less effective at reducing ringing than the other shaping methods. I have also tested with pressure advance set to 0.5.

CadetC

@dc42
I got Duet3 + toolboard ver1.1 installed - Today i have upgraded to 3.4.0beta1-inputshaping (2021-07-11) - i have then used latest binaries to be able use accelerometer in SBC configuration. -when i try to G1 X-50 G4 S2 M956 P121.0 S1000 A0 G4 P10 G1 X50 F20000 i received Error: M956: Accelerometer not found but when i send M120 B121 in response i got : Accelerometer detected: yes, status: 00
Is this got any thing to toolboard still being: Duet TOOL1LC firmware version 3.3 (2021-06-15 16:12:58)? is there any files to upgrade TOOL1LC to 3.4 firmware?

dc42

@cadetc you don't need to upgrade the tool board firmware. I assume you have verified that you are running DSF 3.4.0b1 on the Pi. We are looking into a possible cause of the problem you are having with M956.

CadetC

@dc42
Info copied from DWC : Machine specific-General :
Board: Duet 3 MB6HC (MB6HC)
DSF Version: 3.4-b1
Firmware: RepRapFirmware for Duet 3 MB6HC 3.4.0beta1-inputshaping (2021-07-11)

Thanks,