InputShaping-Plugin-0.1.0-rc6 released

mfs12

just checked. the line counts are ok.

mfs12

@jay_s_uk but they are not exactly the same. you should get an sample rate error and not a sample number error.

The files use different sample rates.

==> 1629703252758-input-shaping-0-z-none.csv <==
Rate 1286, overflows 0

==> 1629703255890-input-shaping-0-y-none.csv <==
Rate 1284, overflows 0

==> 1629703258730-input-shaping-0-x-none.csv <==
Rate 1284, overflows 0

jay_s_uk

@mfs12 so how so I adjust that? they were all recorded using the input shaper plugin

mfs12

@jay_s_uk the easiest way would be to re-record them without tweaking any recording parameters.

jay_s_uk

@mfs12 ok, i've re-recorded and that error has gone. don;t know why it was there in the first place as I hadn't changed any of the parameters

dc42

@jay_s_uk @mfs12 the recorded rate may vary depending on temperature etc. RRF asks the sensor to report at one of its supported nominal rates, then measures the rate at which the sensor actually collects the data. Assuming that the sensor was a LIS3DH then the nominal rate would have been 1344. In this case the change in data rate was less than 0.2% so it could safely be ignored.

CadetC

@mfs12
Look like we need rc7
After installing 3.4b3 rc6 no longer works.

Nuramori

I get the following error:

Prerequisites
Duet Web Control
Version 3.4.0-b3

But I have that installed.

jay_s_uk

@nuramori it needs to be rebuilt for beta 3. It only works on beta 2

mfs12

Thanks for the feedback.

I plan to do another release towards the end of the week.

Fred-Y

@mfs12 That's a detail: when configuring the Input Shaping to none, there is a validation on the frequency - it's not really an issue but Algorithm = none and Frequency = 0 are the defaulted values.

Also, in the filename, would it be possible to include the parameters (frequency and damping) used?
It would be useful when comparing the different graphs.

GeneRisi

This post is deleted!

mfs12

@fred-y, thanks for the feedback.

the parameter handling will get better.

also i am thinking about to store the records in local storage. this way all context, i.e. inputshaping parameters, movement command could be stored together with the record.

But in general the idea is to start a session and improve parameters iteratively and compare to previous runs without changing the initial movement command. So there shouldn't be a need to store this data parmenently.

Fred-Y

@mfs12 the changes you mentioned sound awesome!
I really like the idea of the session, I tried to do something similar with some macros, variables and loops but that was not user friendly

Storing the parameters locally would definitively be nice.

Another detail, it's far from begin the end of the word, This is specific to deltas (or printer having the coordinate 0:0 in the center of the bed) by default the effector is not coming back to the 0.

This is makes the recording not consistent when switching back and forward to a different axis.

Example of recording done back to back:
1-Record X - starts at -165:0 ends at 58:0
2-Record X - starts at -165:0 ends at 58:0
3-Record Y - starts at 58:-165 end at 58:58 -> would be better if it was 0:-165 ends at 0:58
4-Record Y - starts at 58:-165 end at 58:58
5-Record X - starts at -165:58 ands at 58:58 -> not consistent with 1 and 2

Changing the axis in the drop down reset values.

I think storing locally the Start and Stop positions might be the simpler solution, just need to adjust it once and forget about it - not even need to change the calculation for the end position.

And a last one, would it be possible to select (check boxes) which axis we want to capture, I generally have very little interest for the Z axis.

Thanks for making this plugin, I'm sure it will be well used

mfs12

@fred-y said in InputShaping-Plugin-0.1.0-rc6 released:

And a last one, would it be possible to select (check boxes) which axis we want to capture, I generally have very little interest for the Z axis.

we are rather following the approach to display only requested, but record all axis.

dc42

@fred-y to add to what @mfs12 says, other axes can be relevant. On one of my machines, sudden Y movements cause a torsional oscillation of the print head about the X axis, resulting in a Z oscillation. This oscillation affects the layer height and therefore also the extrusion width.

Blacksheep99

Looking forward to the new version to support b3. Any idea when it will be available? Thanks for the great work.

mfs12

This post is deleted!