Accelerometer data interpretation

MikeS

Hi guys,
so i hooked up my accelerometer to my Voron 2.4 and latest beta with input shaping. Board is a Duet 2 Wifi + Duex5. Accelerometer is LIS3DSH and seems to work fairly well.

After checking belt tension i run the 2 readings with the following gcode:

AccelerometroX.gcode

M593 P"none"
G1 X-50 G4 S2  G4 P10 G1 X100 F20000 M956 P0 S1000 A0 F"AsseX.csv"

AccelerometroY.gcode

M593 P"none"
G1 Y-50 G4 S2  G4 P10 G1 Y100 F20000 M956 P0 S1000 A0 F"AsseY.csv"

These are the results i get:

So my question is: is that low frequency amplitude ok? I would pick a frequency of about 30Hz and try ZVD for less smoothing possible but i think that low frequency ringing is not good.

engikeneer

@mikes that very low frequency might be your whole machine moving on its stands... if you can, stick your accelerometer to your bed and repeat the test, that way you can see what is actual ringing and what is rigid body motion of the whole machine.

Or just go for 30Hz and see what happens

MikeS

@engikeneer

This with the accelerometer on the bed. Don't look at axis markin because i didn't change orientation at declaration time. It seems to me that the frame is pretty rigid and "ringing" at low frequency is not generated by the frame. Also consider that the accelerometer is sticked to the bed with tape, so probably the frame is more rigid than what the graphs shows.

engikeneer

@mikes well there goes my theory...

Maybe it's the accelerometer mount? Or some backlash in your rails/belts?

Or could just be an artefact of running the FFT on a short segment of data...

dc42

@mikes said in Accelerometer data interpretation:

G1 X-50 G4 S2 G4 P10 G1 X100 F20000 M956 P0 S1000 A0 F"AsseX.csv"

It may be easier to interpret the data if you use:

G1 X-50 G4 S2 G4 P10 G1 X100 F20000 M400 M956 P0 S1000 A0 F"AsseX.csv"

That way the accelerometer will see only the ringing after the move completes, not the move itself.

~~EDIT: Something isn't right. One of the axes should be showing average acceleration close to 1G.~~

We have an input shaping plugin for DWC under development.

MikeS

@engikeneer accelerometer is mounted in a sturdy way, also i should have no backlash. I don't know if this type of results is common because accelerometer support is new in duet and all other example i see are from the klipper algorithm that uses a different technique to obtain the data from what i saw.

thank you @dc42 :

My fault, i didn't probably revert the orientation...i'll check it!

MikeS

@dc42 so turned out that i was using wrong orientation. Here are the new graphs with the wait for end of move:

Edit: more problems for me to solve... This is the datasheet of the LIS3DSH

and this is what i got:

So definetly something is wrong.

dc42

@mikes it looks like you have a strong resonance at around 64Hz on the X axis. Can you post the raw data before analysis too?

SilviuZ

@dc42 Hello
After using the bellow commands I get those results:
There is any chance that the accelerometer data can be interpreted in a way that can be implemented with input shaping considering that X and Y ring in a total different way?
I am running RRF 3.4 Beta2 on a Duet 3 MB6HC and 1LC V1.1 . The printer axis are Cartesian and quite heavy ( Stratasys FDM 2000 ) but extremely rigid.
Thank you.
G1 X-50 G4 S2 G4 P10 G1 X100 F20000 M400 M956 P121.0 S1000 A0 F"AsseX.csv"
G1 Y-50 G4 S2 G4 P10 G1 Y100 F20000 M400 M956 P121.0 S1000 A0 F"AsseY.csv"
image url)
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0beta2 (2021-08-03 12:42:33) running on Duet 3 MB6HC v0.6 or 1.0 (standalone mode)
Board ID: 08DJM-956L2-G43S8-6JTD6-3SS6L-KA16H
Used output buffers: 3 of 40 (20 max)
=== RTOS ===
Static ram: 151128
Dynamic ram: 93032 of which 0 recycled
Never used RAM 106440, free system stack 152 words
Tasks: NETWORK(ready,29.2%,230) ETHERNET(notifyWait,0.1%,176) HEAT(delaying,0.0%,326) Move(notifyWait,0.0%,280) CanReceiv(notifyWait,0.0%,773) CanSender(notifyWait,0.0%,373) CanClock(delaying,0.0%,340) TMC(notifyWait,9.0%,59) MAIN(running,61.7%,1118) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:32:37 ago, cause: software
Last software reset at 2021-08-05 17:55, reason: User, GCodes spinning, available RAM 106104, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 736
MCU temperature: min 43.5, current 44.5, max 45.2
Supply voltage: min 29.2, current 29.3, max 29.4, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 11.8, current 12.1, max 12.6, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 126480, standstill, reads 62138, writes 22 timeouts 0, SG min/max 0/1023
Driver 1: position 126480, standstill, reads 62138, writes 22 timeouts 0, SG min/max 0/1023
Driver 2: position 0, standstill, reads 62143, writes 17 timeouts 0, SG min/max 0/784
Driver 3: position 0, standstill, reads 62150, writes 11 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 62150, writes 11 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 62150, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2021-08-05 18:27:59
Slowest loop: 124.51ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 0.8ms, write time 3.1ms, max retries 0
=== Move ===
DMs created 125, segments created 3, maxWait 25575ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 18, completed moves 18, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== 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 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 2 -1 -1 -1
=== 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
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 17640, received 15810, lost 0, longest wait 2ms for reply type 6049, peak Tx sync delay 301, free buffers 49 (min 48), ts 9790/9789/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 17.10ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 1 of 8

Ethernet -
State: active
Error counts: 0 0 0 0 0
Socket states: 5 2 2 2 2 0 0 0

sebkritikel

@silviuz said in Accelerometer data interpretation:

Not exactly scientific, but check out the magnitudes of the X and Y vibrations. Typically the recommendation is to select an input shaping frequency that is the lowest of the frequencies of interest. For both you Y and X tests, you have X-axis peaks around 61Hz, at amplitudes between .0025-.0035. Y-axis peaks at ~.0055, which is higher than the X peaks, and occurs at ~41Hz. My thoughts are that if you select ~41Hz as your input shaping frequency, you'll target the worst frequency of the entire system.

Also, super cool on converting a Stratasys FDM 2000 over to the Duet ecosystem.

SilviuZ

@sebkritikel
Thank you! I will try to implement your recommendations
image url)

dc42

@silviuz you can also choose EI3 input shaping centred on a frequency between the X and Y ringing frequencies, which should be fairly effective at suppressing both.

SilviuZ

@dc42 Thank you for your reply.
I've tried 41HZ without a significant success.
After a couple of ringhing towers I found that indeed "ei3" it's doing the best cancellation at 28HZ.
I hope that in the future if it's possible..... to have implemented a automatic axis tuning similar like the Teknic Clearpath.
Thank you again for your help.

MikeS

@dc42 Sorry for the delay. I figured out that despite the chip is marked differently than the image on the datasheet, the axed are oriented in the same way. To test it i did statical reading while holding the accelerometers in different position and checking if the expected axes reported nearly 1g.

Now that i have figured that out, here's the results of the previous macros before and after FFT:

X AXIS:

Y AXIS:

Edit:
There's seems to be something wrong when selecting axes to be acquired with M956.
If i don't specify axes, i get all the readings (but i don't know if they are in the correct order).
If i specify X then i get readings
I i specify Y i get all 0 values
I i specify XY i get same values for X as only X and all 0 values for Y
I i specify XYZ i get same results as nothing specified.

Here's some graph:

ONLY X

ONLY Y

X AND Y

Code (changed axes just after M956)

M593 P"none"
G1 Y-50 G4 S2 G4 P10 G1 Y100 F20000 M400 M956 X P0 S1000 A0 F"test.csv"

dc42

@mikes said in Accelerometer data interpretation:

There's seems to be something wrong when selecting axes to be acquired with M956.
If i don't specify axes, i get all the readings (but i don't know if they are in the correct order).
If i specify X then i get readings
I i specify Y i get all 0 values
I i specify XY i get same values for X as only X and all 0 values for Y
I i specify XYZ i get same results as nothing specified.

Thanks, I'll check it. It could be that incorrect values are stored in the .csv files, or the plugin is interpreting them the wrong way. Can you open the .csv files in the System tab of DWC and see if the data and column headings look OK?

MikeS

@dc42 csv is displayed correctly as csv contains 0 for each row in Y axis.

dc42

@mikes thanks, the problem is in RRF then.

dc42

@mikes this issue is now fixed in the source code. The fix will be included in the next beta.

MikeS

@dc42 thank you David. Any chance to get a compiled binaries for Duet2wifi to test it out? Still have to test input shaping because i was not sure if the data was reliable... i saw resonance on Z axis for example while testing X or Y axis.

MikeS

@dc42 just had 2 hours to play with a VM and managed to compile the source.

On the current source i can read correct data from X and Y axes (both together or alone) but Z axis is always reading -1.9995 as value. Also X Values is near -2 and it seems not correct to me. Shouldn't X and Y be near 0 and Z to -1 with a reading without moves?

~~UPDATE:~~
~~So i've looked at the changes you made in the latest version and came up with this fix:~~

~~I am not a programmer, but i've tested it and it seems that it has fixed it. Can you confirm?Maybe it's only another error that fixes my particular issue~~

Nevermind all! I've looked more at C++ language and understood that in the for loop ++i has the same behaviour of i++ so that was not the fix. However now it seems to be working fine. I'll do more tests but it seems that there was something wrong with the accelerometers itself, returning wrong data...