@caijonas you get the error message "session does not match record's numer of samples" when you try to load different "records" with different numbers of samples.
Ususally you try to compare graphs from different recordings sessions where you were using different paramters. They are not comparable. At least so far.
@mfs12 i get that message when loading different graphs recorded using the same parameters
@jay_s_uk did one graph have overflows?
@mfs12 how do I verify that?
@jay_s_uk if there were overflows you usually get asked. At least if it's the first record to load.
Or download the files and count the lines on Linux/MacOS you can use "wc -l" for that.
$ cat RECORDED_FILE.csv | wc -l
Here's the check that is failing...
just checked. the line counts are ok.
@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
@mfs12 so how so I adjust that? they were all recorded using the input shaper plugin
@jay_s_uk the easiest way would be to re-record them without tweaking any recording parameters.
@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
@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 last edited by
Look like we need rc7
After installing 3.4b3 rc6 no longer works.
Nuramori last edited by
I get the following error:
Duet Web Control
But I have that installed.
@nuramori it needs to be rebuilt for beta 3. It only works on beta 2
Thanks for the feedback.
I plan to do another release towards the end of the week.
Fred-Y last edited by 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 last edited by
This post is deleted!
@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 last edited by
@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
Blacksheep99 last edited by
Looking forward to the new version to support b3. Any idea when it will be available? Thanks for the great work.
This post is deleted!