InputShaping-Plugin-0.2.0-pre7 released

[ajdtreyd]

Should it be possible to add more than one axis to a single session?
I have tried adding tests for X and Y axis to a single session and then when recording, all tests are run, but only along the axis which was selected for the last configured test.

thanks!

[CNCModeller]

@cncmodeller said in InputShaping-Plugin-0.2.0-pre7 released:

Hi All,
I'm getting Error: M956: Response timeout: CAN addr 123, req type 4014, RID=6.

Any thoughts on what this is related too? It used to work with pre6.

I think it could be related to I'm measuring a polar printer bed and I now have limits on bed acceleration and rotation speed since the bug was fixed in M669.

Any thought would be much appreciated.

Cheers
Barry M

Update, I've increased bed speed and Accel limits by an order of magnitude and the bed now behaves as in pre6 but I'm still getting the error.

[sebkritikel]

Good updates all around!

My only report is removing algorithm run data from the current selection resets the chart view to the 'Time' plot - this is in contrast to removing axis data, which keeps the chart (time or FFT) active.

@ajdtreyd I agree, it would be nice to nice to run different axis tests under a single 'configuration' session. The axis setup & bounds could fall under each algorithm you add.

[ajdtreyd]

Found a bug!

I used -75 and 75 as my start positions for the initial config of my sessions. After doing record and running recommendations, I selected a couple of algorithms and added them to the session. All good. But when I went back to the CONFIGURE tab the start positions had reverted to the defaults of -115 and 41.
I figured this was just a GUI issue and ran the recordings, but the newly added algos used the default start positions.

Another "nice to have" (but not a bug) is to reset the Input Shaping mode to it's original state when 1) the recording phase has finished AND 2) when the recommendations have completed. Currently M593 mode is left with whatever setting was last used by the plugin.
I have this in my bed.g so probing uses very low accel/jerk and then the original values are reset:

; -- set accel/jerk vars to current values
var x_accel=move.axes[0].acceleration  ;set variable to current acceleration
var x_jerk=move.axes[0].jerk  ;set variable to current jerk
var y_accel=move.axes[1].acceleration  ;set variable to current acceleration
var y_jerk=move.axes[1].jerk  ;set variable to current jerk
var z_accel=move.axes[2].acceleration  ;set variable to current acceleration
var z_jerk=move.axes[2].jerk  ;set variable to current jerk
. . .
M201 X{var.x_accel} Y{var.y_accel} Z{var.z_accel} ;restore orig accel
M566 X{var.x_jerk} Y{var.y_jerk} Z{var.z_jerk} ;restore orig jerk

Overall the plugin is working really nicely!
Thanks!

[dc42]

@cncmodeller said in InputShaping-Plugin-0.2.0-pre7 released:

I'm getting Error: M956: Response timeout: CAN addr 123, req type 4014, RID=6.

That indicates that board 123 is not responding to a CAN command. It's probably not running the correct firmware version.

[mfs12]

@ajdtreyd said in InputShaping-Plugin-0.2.0-pre7 released:

Should it be possible to add more than one axis to a single session?

Right now you have exactly one test movement per session. This helps to keep things separated. When you start to mix all different test you loose pretty fast the overview. So it makes sense to me to keep things separated.

But there might be some further changes in future.

[Fred-Y]

A suggestion would be to add a Z position, this is mainly an issue with Delta as the recording will fail if we don’t move down the effector after having homed the printer.

---

I'm having a lot of crashes when I try to launch the recording, the Duet 2 Wifi just seems to reboot - I didn't see any error.

It doesn't appears to be related to the algorithm selected (happen even with none) or the number of recordings.
I will try to spend more time to see if I can find anything that could help to figure out what could be the reason.

Let me know if there is anything I can do to help trouble shooting this issue.

---

These recommendations seem wrong to me - I’m not an expert so I can be wrong.

I ran without compensation

All recommendations are on the frequency 10.82Hz; I feel it would be better to compensate something between 64 and 72Hz.

The spike at 102Hz is not generated by any movement, it exists when doing recording without a move.

[dc42]

@fred-y said in InputShaping-Plugin-0.2.0-pre7 released:

It doesn't appears to be related to the algorithm selected (happen even with none) or the number of recordings.

Please post a M122 report taken after one of those reboots.

[Fred-Y]

@dc42 I did a lot of tests yesterday but I have not been able to reproduce the issue (reboot) I had.
I'm unsure what caused it I haven't changed anything: same config and wiring ... the board is a few years old maybe something starts to wear.

I'm planning to do more testing within the next few days and I will report back with a log if it is happening again.

[A Former User]

Good morning, I've been able to make my accelerometer to work! I'm trying the plugin but (again) there's something I'm missing, I'm afraid.
I've created two analysis, the first for the X axis and the second for the Y axis, these are the results:

X axis:

Y axis:

Why does the plugin suggest me 10,87/88Hz as frequence? Particullary for the Y axis the spike is at 67.8 Hz wich is about where I expected it to be....what's wrong? CoreXY printer, here my M122:

13/11/2021, 07:52:25	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta6 (2021-11-06 11:37:41) running on Duet WiFi 1.02 or later
Board ID: 08DLM-996RU-N85T0-6JKFJ-3SD6R-9SSHN
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 23772
Dynamic ram: 79576 of which 12 recycled
Never used RAM 5408, free system stack 118 words
Tasks: NETWORK(ready,16.6%,234) ACCEL(notifyWait,0.1%,244) HEAT(notifyWait,0.0%,326) Move(notifyWait,0.0%,283) MAIN(running,83.2%,440) IDLE(ready,0.2%,30), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:09:52 ago, cause: software
Last software reset at 2021-11-13 07:42, reason: User, GCodes spinning, available RAM 5408, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x0c
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 32.6, current 33.2, max 33.9
Supply voltage: min 23.9, current 24.0, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/10, heap memory allocated/used/recyclable 2048/672/472, gc cycles 0
Driver 0: pos 74214, standstill, SG min 0
Driver 1: pos -21546, standstill, SG min 0
Driver 2: pos 6345, standstill, SG min 29
Driver 3: pos 0, standstill, SG min n/a
Driver 4: pos 0, standstill, SG min n/a
Driver 5: pos 0
Driver 6: pos 0
Driver 7: pos 0
Driver 8: pos 0
Driver 9: pos 0
Driver 10: pos 0
Driver 11: pos 0
Date/time: 2021-11-13 07:52:23
Cache data hit count 4294967295
Slowest loop: 50.36ms; fastest: 0.09ms
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 3.4ms, write time 39.6ms, max retries 0
=== Move ===
DMs created 83, segments created 19, maxWait 118823ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 19, completed 19, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], 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 -1 -1 -1 -1, ordering errs 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== Filament sensors ===
Extruder 0: pos 0.00, errs: frame 1 parity 0 ovrun 0 pol 0 ovdue 0
Extruder 1: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
=== Network ===
Slowest loop: 80.25ms; fastest: 0.00ms
Responder states: HTTP(0) 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 0
WiFi firmware version 1.26
WiFi MAC address 84:0d:8e:b3:bc:96
WiFi Vcc 3.45, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25264
WiFi IP address 192.168.1.7
WiFi signal strength -47dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 2 4 0 0 0 0 0 0

Thanks!

[gloomyandy]

@thedragonlord You really need to run a base line test for each axis (so set the input shaper to "none") and then use that as the input to the recommendation stage. However I suspect that this will still select too low a frequency (as reported by Fred-Y above and I see the same thing). However by having the base results (with no input shaper), you may be able to judge for yourself what other tests to run and what frequency will work best for you. Remember that at the moment RRF only supports a single shaper for X and Y so you will need to select on that basis.

@mfs12 Are there any plans to change the way that the recommendations selects the target frequency? At the moment it always seems to select something that is too low.

[gloomyandy]

@thedragonlord You might find the thread I started on input shaping of interest: https://forum.duet3d.com/topic/25931/input-shaping-testing-and-thoughts

[T3P3Tony]

@fred-y said in InputShaping-Plugin-0.2.0-pre7 released:

this is mainly an issue with Delta as the recording will fail if we don’t move down the effector after having homed the printer.

Its a good idea to move your effector down at the end of homedelta.g to a position where any XY commands that are valid will not crash the carriages at the top of the endstops.

[ajdtreyd]

@fred-y said in InputShaping-Plugin-0.2.0-pre7 released:

A suggestion would be to add a Z position, this is mainly an issue with Delta as the recording will fail if we don’t move down the effector after having homed the printer.

+1 for this

Also, to take this a bit further, it would be nice to be able to specify test moves by XYZ coordinates. On deltas (mine, at least) the resonances vary a lot based on effector position and direction of travel. Currently I do this using the Accelerometer plugin, but that has no way to overlay FFT graphs of multiple recordings and it takes a long time to do comparisons.

Hehehe ... sounds like I'm complaining, but this tuning process is soooo much better than it was in 3.3!

[Fred-Y]

@t3p3tony Actually the firmware has been properly coded to handle this situation as it prevents these moves.

But I like your recommendation to move down the effector at the end of the homedelta file, I know some slicers (at least IdeaMaker) starts to move the effector on X/Y before moving down the effector causing an error.

[A Former User]

@gloomyandy said in InputShaping-Plugin-0.2.0-pre7 released:

@thedragonlord You really need to run a base line test for each axis (so set the input shaper to "none") and then use that as the input to the recommendation stage. However I suspect that this will still select too low a frequency (as reported by Fred-Y above and I see the same thing). However by having the base results (with no input shaper), you may be able to judge for yourself what other tests to run and what frequency will work best for you. Remember that at the moment RRF only supports a single shaper for X and Y so you will need to select on that basis.

@mfs12 Are there any plans to change the way that the recommendations selects the target frequency? At the moment it always seems to select something that is too low.

Ok, but it's not clear, after using the recomendation, how to choose the frequency to set in the M593....all the recomendation displays the same frequency....is this a plugin's bug? I know it's my fault due to my ignorance but except for the analysis I really can't understand how to use this plugin..

[gloomyandy]

@thedragonlord Yes, it looks like the frequency chosen is not correct and it is probably a bug (which is why I was asking @mfs12 about it). Remember that this is all new software (and still not a final release), so there are likely to be problems.

[A Former User]

@gloomyandy said in InputShaping-Plugin-0.2.0-pre7 released:

@thedragonlord Yes, it looks like the frequency chosen is not correct and it is probably a bug (which is why I was asking @mfs12 about it). Remember that this is all new software (and still not a final release), so there are likely to be problems.

Sure, I'm a programmer and I know well what it means to deliver a new software! I was asking just to be sure that I did understand how the plugin was supposed to work...for the fix we'll wait, no problem at all

[Gixxerfast]

I second this, I'm also working with software dev so I'm fully aware of the iteration cycles. Happy that someone is spending their time implementing this functionality.

The reason I started my thread, unaware of others though I spend too much time reading stuff here, was that I found it unclear wether this was a bug or something intentional.

[mfs12]

So far the plugin is still experimental, I am having trouble doing the calculation of the response. Apparently it's dead simple according to an excel-sheet i have. But i wasn't able to reproduce this reliable in javascript. Until then this plugin is a little useless.

So far it's just useful to record and review shaper configurations.