RRF 3.4 input shaping preview available

[dc42]

I've put some RRF 3.4alpha binaries for Duet WiFi/Ethernet, Duet 3 MB6HC and Duet 3 Mini at https://www.dropbox.com/sh/l020weqx7pijv84/AACFM3knhVXQ1hKu6NyKOfx6a?dl=0. Feel free to try them - but at your own risk! I have done prints using the Duet 2 non-SBC build and the Duet 3 MB6HC build, but the other builds are untested.

These builds are compatible with DWC 3.3.0, DSF 3.3.0, and Duet 3 expansion/tool board firmware 3.3 stable. There are some limitations:

• Input shaping is not applied to axes controlled by stepper motors driven from CAN-connected Duet 3 expansion boards.
• There is no build yet for the Duet Maestro.
• I am not certain that extrusion is always calculated correctly when using an extruder drive connected to a CAN-connected expansion board, especially when pressure advance is in use.
• If you use segmented kinematics, or you enable segmentation even though you use non-segmented (e.g. Cartesian, CoreXY or delta) kinematics, then input shaping won't be applied if the segments are too small.

If you do try this firmware, please start by doing basic homing and movement tests, to check that everything is working as expected. Then do a print that you have done before without enabling input shaping, to check that you get the same result. After that you can try the effect of enabling input shaping.

I have created a wiki page about input shaping at https://duet3d.dozuki.com/Wiki/Input_shaping and I will add more content later today.

Here are some prints of the Klipper ringing test part https://www.klipper3d.org/prints/ringing_tower.stl that I did yesterday and this morning. First a print from my delta:

The ghosting is very light on this machine and I had to set up the lighting and camera angle very carefully to photograph it. The damping is quite high (the ghosting fades after just a few ripples). It can be seen that ZVD shaping reduces the ringing a little, and ZVDD and higher virtually eliminate it. This suggests that either ringing is occurring over a range of frequencies (which is probably normal pn a delta), or I didn't set the M593 F parameter quite right.

Here is a print from my E3D Tool Changer with Hemera tool. In this case the primary ringing detected by the accelerometer appears to be a torsional oscillation of the print head about the X gantry. The damping in this case is very low (the ghosting persists for many ripples). All types of input shaping reduce the ghosting, with ZVD being a little less effective than the other forms.

I welcome your feedback on these binaries in this thread. I won't be able to work much on this next week, so it may be a while before I can implement any fixes that may be needed.

[oozeBot]

@dc42 is it working with an SBC yet? Thanks

[dc42]

@oozebot input shaping works with SBC already. Accelerometer support with SBC is being worked on.

[oozeBot]

@dc42 My mistake. Thanks! We'll give it a go!

[Nuramori]

Just ran it on a coreXY - that was..... not successful. Everything seemed to work fine (homed correctly, bed leveled), but as soon as it went to print, it sounded like my steppers exploded. lol. Home to 0,0 seemed reversed, and just had to hit the e-stop for the first time in a long time.

Not sure I want to try that again to even get a short video.

[CCS86]

Exciting!

Any more insight on viability or timeline for a Maestro build?

[dc42]

@nuramori said in RRF 3.4 input shaping preview available:

Just ran it on a coreXY - that was..... not successful. Everything seemed to work fine (homed correctly, bed leveled), but as soon as it went to print, it sounded like my steppers exploded. lol. Home to 0,0 seemed reversed, and just had to hit the e-stop for the first time in a long time.

Not sure I want to try that again to even get a short video.

Were you running RRF 3.3 stable already?

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