New Input Shaping plugin v3.4.1-b1

dc42

@argo the EI shapers accept up to 5% residual ringing in return for covering a wider bandwidth. Perhaps that us what you are seeing?

Also try setting the damping factor to zero if you haven't already.

nuroo

Hey guys,

Great work here 1st off.
I'm having a strange issue. Last night I had over 10 successful tuning runs with this plugin. I was on my way to finding the best input shaper for my setup. Around the 12th or 13th run the plugin started crashing after the 1st X-axis move. When it crashes the dwc becomes frozen and an automatic restart is triggered, similar to if I had pressed the stop button. I have uninstalled the plugin and reinstalled it, still crashes. I've tried doing a baseline run, no input shaper - but these also now crash.

In case it's my issue I will do a wire continuity test from sensor thru wiring to connector for duet board, maybe the repeated movement caused the issue. I have also tried tuning only a single axis.

In my config.g
M955 P0 C"spi.cs6+spi.cs5" I41 Q2000000
To troubleshoot I tried:
M955 P0 C"spi.cs6+spi.cs5" I41 Q1000000 <---still crashes

Railcore 2 zl 300
Input Shaping 3.4.0-b1
Duet web control 3.4.0
Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.4.0 (2022-03-15)
Duet WiFi Server Version: 1.26

alt text

zapta

Documentation looks very nice. I should reconnect my accelerometer and give it a try.

Is the damping factor also something that need to be configured with M593?

dc42

@nuroo please post a M122 report taken after the automatic restart.

nuroo

@dc42

Must have been a wiring issue. I dont know really. Maybe it was the temp condition of my wiring job. Using servo wire that wasn't long enough, couplers, mismatched connectors, etc. Last night after re-hot gluing the connectors I still had an issue. Today at work I see your post m122 comment, come home and it works.

¯\_(ツ)_/¯

If i have issues in the future I'll wire a fully soldered custom wiring harness with no connectors in the middle.

oliof

@oliof @oozeBot a little follow-up about my note on M203: It may be that M203 needs to be set at (target speed) x sqrt(2) mm/s to allow for target speed to be reached due to the differential input in a CoreXY system. In preliminary testing on a CoreXY system this seems to be the case at least. I leave to @dc42 to decide whether this is a bug or undesirable side effect of CoreXY, but it surely is unexpected. So are you sure the machine goes the full 400mm/sec on the input shaping measurement move, or does it maybe end up "only" going 283mm/sec?

dc42

@oliof I believe it will reach the full speed as defined by the lesser of the F parameter and the M303 limits, provided that the acceleration limits is high enough and the move long enough to reach that speed. The requested and top speeds will be shown by DWC if the sample shown by DWC happens during the move.

martink

@nuroo

Don't know if related, but before this plugin was available, when I first got my accelerometer, I wrote some gcode to collect accelerometer data for a number of moves along x, y axes and diagonals (8 M956 measurements per run of my macro).

After running the macro successfully several times, RRF (a 3.4 beta at the time) crashed (during one of the M956 commands, I think) and I had to hard reset the board. I think I even had to cut 5V power (i.e. unplug the USB between my RPi and my Duet 2).

Like in your case, this only happened after many measurements. Also, like you, my accelerometer is connected to the Duex (spi.cs8+spi.cs7 in my case). But my wiring was a cat5 cable with an IDC connector on the duet end and 5 pin + 2 pin JST XH connectors on the accelerometer end (Adafruit LIS3DH).

On that day, I could repro the problem a couple times. But by the time I was going to report the problem and collect some debug logs, it stopped reproducing for me. I haven't tried the new plugin yet.

nuroo

@martink
Was the strangest thing. I know my harness was "fugazi", but if yours was legit. If it's something else like a power panic or buffer over flow I'll try the hard power reset next time.
Thanks for posting your experience. Felt like printer was trolling me,

Diamondback

Nice work!

Little bug report: I'm being displayed this message despite not having any toolboards. My printer IS a TC, however, it uses a Duet 2 + Duex5 and a standalone accelerometer.

chrishamm

@diamondback Thanks, I'll fix it in the next version.

RatRig0331

I’m new to using the accelerometer, everything seems happy with the set up and wiring I have, but when I go to run this plugin the printer head rapids to the right and than the duet mainboard shuts down and restarts. I’ve tried it 4 times and the same thing every time happens. I’m using it on a rat rig xy core set up 500x500x500mm

jay_s_uk

@ratrig0331 post an output from M122 after the reboot occurs

bekzclz11

his is a simple demo plugin for DWC 3.4.0 to be uploaded either on "Upload&Start", "System Files", or "Plugins -> External Plugins".
It registers a new tab under Settings -> Machine -> Endstops where the endstop states of each axis can be observed.

ctilley79

@SputnikOC3d download this Steve.

RatRig0331

@jay_s_uk
m122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.4.0 (2022-03-15 18:59:15) running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: G1R6K-M396U-D65J0-40KM4-3G03Z-HZ0QD
Used output buffers: 1 of 40 (16 max)
=== RTOS ===
Static ram: 103684
Dynamic ram: 100772 of which 20 recycled
Never used RAM 37236, free system stack 206 words
Tasks: ACCEL(notifyWait,0.0%,346) SBC(ready,3.6%,473) HEAT(notifyWait,0.0%,358) Move(notifyWait,0.0%,363) CanReceiv(notifyWait,0.0%,942) CanSender(notifyWait,0.0%,372) CanClock(delaying,0.0%,339) TMC(notifyWait,1.2%,115) MAIN(running,94.4%,384) IDLE(ready,0.0%,29) AIN(delaying,0.8%,264), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:02:51 ago, cause: software
Last software reset at 2022-04-13 22:15, reason: HeatTaskStuck, GCodes spinning, available RAM 33300, slot 2
Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0000080f BFAR 0xe000ed38 SP 0x20031c0c Task ACCE Freestk 334 ok
Stack: 00000001 00053fcc 210c0000 00000000 404b5800 369dc3a0 3edb7e85 3331bb4c 40000000 b5ddc58d 388ab355 bb360b61 3e2aaaab 3f800000 42fa0000 3ca3d70a 40000000 43800000 3d600000 00000000 00053e1f 20031588 20031588 00000006 0008649f 00000000 20031588
Error status: 0x00
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 171323, completed 171323, timed out 0, errs 0
Step timer max interval 1472
MCU temperature: min 31.1, current 31.1, max 32.8
Supply voltage: min 24.0, current 24.0, max 24.0, 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
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 2, read errors 0, write errors 0, ifcnt 135, reads 9165, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 135, reads 9165, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 2, read errors 0, write errors 0, ifcnt 135, reads 9166, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 58, read errors 0, write errors 0, ifcnt 137, reads 9166, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 78, read errors 0, write errors 0, ifcnt 137, reads 9165, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 5: standstill, SG min 170, read errors 0, write errors 0, ifcnt 119, reads 9165, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 6: standstill, SG min 0, read errors 0, write errors 0, ifcnt 69, reads 9166, writes 0, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2022-04-13 22:18:32
Cache data hit count 376716422
Slowest loop: 7.60ms; fastest: 0.09ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters 2 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" 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
=== CAN ===
Messages queued 907, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 18), ts 504/0/0
Tx timeouts 0,0,504,0,0,403 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 4, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 12442/6677
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0, IAP RAM available 0x0f1ec
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.0
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 38.79, max time between full transfers: 43.2ms, max pin wait times: 27.7ms/0.2ms
Codes per second: 0.01
Maximum length of RX/TX data transfers: 4204/1532

dc42

@ratrig0331 thanks for your M122 report. I've seen this issue once before. I am fairly sure it is caused by problems with the accelerometer wiring that result in communication issues between the accelerometer and the Duet.

Schild0r

I noticed just today, that this plugin existed. Must have been two days before release or so that I wrote a macro myself for doing this. (see below)

Turns out I basically hit bullseye by accident with my shaper settings after running my macro and now comparing the results with the plugin, just because I did not know that MZV would dampen two frequency amplitudes and the second one did luckily coincide perfectly with the amplitude of my x-axis

But the user Interface of the plugin is very good especially the merged frequency analyses of multiple axis and the damping curves preview for the shapers.
Only thing I would like to add though are inputs for the acceleration and speed at which the accelerometer data is collected.
Just a little QOL thing with e.g. a tickbox for "use maximum speeds and accelerations from current config" and if you untick it, you can enter your own values so that they are set before starting the sequence automatically instead of the user having to enter them manually before going to the plugin.
Oh and returning the printhead back to the center position after the last move would not trigger my OCD

Also a little sidenote if a dev reads this:
We now have Height Map in the Control tab
The Accelerometer Viewer in Machine Specific under the Settings tab
and the Input Shaping Plugin under the Plugins tab
One could also debate about the G-Code Viewer (I personally like it under the Job tab) but at least the above three (and maybe even the Object Model browser) are pretty similar and thus should be under the same tab IMO.
Please feel free to discuss my opinion though.

the macro if anyone is interested:

var origXAccel = move.axes[0].acceleration
var origYAccel = move.axes[1].acceleration
var feedrate = move.axes[0].speed

if exists(param.F)
	set var.feedrate = {param.F}
	echo "speed for accelerometer data collection:", {var.feedrate/60}, "mm/s"
else
	echo "param.F not provided, instead maximum speed (X) is used for accelerometer data collection:", {var.feedrate/60}, "mm/s"

G28
G1 X{move.axes[0].max/2} Y{move.axes[1].max/2} F9000

if exists(param.A)
	echo "setting X and Y acceleration to", {param.A}, "mm/s^2"
	M201 X{param.A} Y{param.A}
	M201
else
	echo "param.A not provided, using current accelerations X:", {var.origXAccel}, "mm/s^2, Y:", {var.origXAccel}, "mm/s^2"

echo "collecting acceleration data for X-Axis"
G91 ; relative positioning
G1 X-50 F9000
G4 S2 
M956 P21.0 S1000 A1 F"inputShapingX.csv"
G1 X100 F{var.feedrate} 
G4 S2

echo "collecting acceleration data for Y-Axis"
G1 X-50 Y-50 F9000
G4 S2 
M956 P21.0 S1000 A1 F"inputShapingY.csv"
G1 Y100 F{var.feedrate} 
G4 S2
G1 Y-50 F9000
G90 ; absolute positioning

if exists(param.A)
	echo "reverting changes in acceleration"
	M201 X{var.origXAccel} Y{var.origYAccel}
	M201

T3P3Tony

@schild0r said in New Input Shaping plugin v3.4.0-b1:

We now have Height Map in the Control tab
The Accelerometer Viewer in Machine Specific under the Settings tab
and the Input Shaping Plugin under the Plugins tab
One could also debate about the G-Code Viewer (I personally like it under the Job tab) but at least the above three (and maybe even the Object Model browser) are pretty similar and thus should be under the same tab IMO.

this is a good point. The different features are implemented at different levels of "core" from build in from a long time ago to a new and experimental plugin, so the UI location is more based on that than on a logical place for them to be from a user use perspective. We will think about how this could work going forward, especailly as we want to encourage more plugins to the UI.

RatRig0331

@dc42
It did seem to be my connections I soldered the wires directly to the accelerometer chip with a pig tail plug vs the screw post terminals I had soldered to the chip and everything seems fine now, I still have no clue what to do with the data collected yet but I’m here to learn