Periodicity of ringing

burtoogle

@dragonn said in Periodicity of ringing:

Oh, sorry for misunderstanding. In this situation it would makes sens to test high jerk with less acl so for example 1600 acl and jerk 600

OK, doing it now...

burtoogle

The print using jerk 650 and accel 1600 looks (as best as I can tell) identical to the print using jerk 300 and accel 1600. However, a factor here could be that because I am using a flex3drive extruder, the E jerk/accel are low (jerk 10, accel 400).

dc42

@burtoogle, by my calculations there is a critical acceleration value calculated as (print_speed - jerk)/ringing_period. For you this works out as (40-5)/0.025 =1400. At this acceleration, or sub multiples of it such as 700, there should be almost no ringing. At twice this acceleration or more there will be a lot of ringing. At 2/3 of this acceleration there should also be noticeable ringing. That is why I suggested you try 1030 (before I was allowing for jerk; 930 would be the value allowing for jerk).

This calculation only considers the contribution of acceleration to ringing, not the contribution of jerk, and only ringing that occurs when one print move follows another.

Phaedrux

Interesting. I'll have to do some testing. I've been having a tough time eliminating ringing at anything over 300 or so acceleration.

mrehorstdmd

@dc42 Does this apply to cartesian mechanisms or is it a delta-only phenomenon? I can test on my corexy ...

dc42

@mrehorstdmd said in Periodicity of ringing:

@dc42 Does this apply to cartesian mechanisms or is it a delta-only phenomenon? I can test on my corexy ...

It should apply to Cartesian and CoreXY too, however there may be different periods of ringing in the X and Y directions because of the differing amounts of mass being moved.

RCarlyle

Interesting concept, though I'm not exactly sure what @dc42 is suspecting is happening. I do want to say that if you're doing corner quality tests with accel and jerk changes, you need to be using an extruder with much higher effective jerk/accel settings so the extruder limits aren't ever controlling corner speed. (EG calculate out your linear filament speed through the print moves.)

AFAIK, the jerk / velocity-jump to zero at the end the segment prior to the corner are the primary cause of visible ringing, because that's what creates the transverse oscillation you see in the segment after the corner. Decel, jerk out of the corner, and accel into the next segment should be much smaller effects.

Different kinematics and trajectories are going to make a difference though... even on a Cartesian machine, you have slightly different stuff happening when you do a turn from 0 degree heading to 90 degree heading, versus 45 degree heading to 135 degree heading. The motors and linear rods see different forces in these cases, even though most firmware treats these as equivalent.

dc42

@rcarlyle said in Periodicity of ringing:

AFAIK, the jerk / velocity-jump to zero at the end the segment prior to the corner are the primary cause of visible ringing, because that's what creates the transverse oscillation you see in the segment after the corner. Decel, jerk out of the corner, and accel into the next segment should be much smaller effects.

According to my calculations, the critical value is the ratio of the deceleration time of the previous move to the period of the ringing that is causing the trouble. The configured jerk reduces the acceleration time, but otherwise doesn't have much effect unless you have troublesome high frequency resonances too.

If P is the period of the ringing and T is the deceleration time of the previous move, then I calculate that if T is significantly less than P but the velocity change is significant, you will get severe ringing and there is nothing you can do about it. S-curve acceleration will make it worse. When T = P the ringing is almost completely cancelled out if you use constant acceleration, but will still be bad using S-curve acceleration (allowing for using double the peak acceleration to get the same acceleration time). When T reaches 1.3P then S-curve acceleration starts to be better. The higher the ratio of T to P, the greater the advantage of S-curve acceleration.

I need to do some beer-glass tests to confirm these theoretical results. If they are confirmed, then for many printers, controlling the acceleration time will be more effective than using S-curve acceleration.

Different kinematics and trajectories are going to make a difference though... even on a Cartesian machine, you have slightly different stuff happening when you do a turn from 0 degree heading to 90 degree heading, versus 45 degree heading to 135 degree heading. The motors and linear rods see different forces in these cases, even though most firmware treats these as equivalent.

Yes, however I think the time spent accelerating and decelerating will still be the most important factor. Another complication is that on a Cartesian machine the X and Y axis ringing frequencies will be different.

I have also been working out the stiffness of motors and belts in order to work out what ranges of ringing period are inevitable, which in turn affects the accelerations that can be used.

burtoogle

@rcarlyle said in Periodicity of ringing:

I do want to say that if you're doing corner quality tests with accel and jerk changes, you need to be using an extruder with much higher effective jerk/accel settings so the extruder limits aren't ever controlling corner speed. (EG calculate out your linear filament speed through the print moves.)

That's what I thought, the flex3drive extruder likes low values so it's probably not the best bit of kit for these tests.

daveidmx

My default profile has bulging corners but almost no visible ringing, but I'm happy to run some tests for you with more aggressive settings. (Looking forward to the new motion planner!)

Can you give me a table of test values you'd like to see? For reference, I'm on a CoreXY with a default profile of 180 jerk, 3600 accel, 60mm/s external perimeters. With these values, I have no observable ringing on the X-axis, and (if I squint hard and use a flashlight) 0.6mm wavelength on the Y for an 0.01s period, assuming it was up to speed at that point.

dc42

@daveidmx said in Periodicity of ringing:

My default profile has bulging corners but almost no visible ringing, but I'm happy to run some tests for you with more aggressive settings. (Looking forward to the new motion planner!)

Can you give me a table of test values you'd like to see? For reference, I'm on a CoreXY with a default profile of 180 jerk, 3600 accel, 60mm/s external perimeters. With these values, I have no observable ringing on the X-axis, and (if I squint hard and use a flashlight) 0.6mm wavelength on the Y for an 0.01s period, assuming it was up to speed at that point.

If your ringing period is as low as 10ms, that's very good. If you see the ringing on the cube fave that is parallel to the Y axis, then it's actually the X axis that is ringing.

Your acceleration time is (60-3)/3600 = 15.8ms. This is longer than the ringing period, which is why ringing is low. If you increase the acceleration time to 20ms or reduce it to 10ms then the ringing should disappear. If you reduce the acceleration time to be below 10ms then the ringing should get a lot worse.

daveidmx

@dc42 Confirmed.

I scripted up a test print that linearly increases the acceleration with Z-height from "0" (60) up to 9000. Ringing indeed becomes prominent as the acceleration time falls down towards and below the ringing period.

dc42

@daveidmx said in Periodicity of ringing:

@dc42 Confirmed.

I scripted up a test print that linearly increases the acceleration with Z-height from "0" (60) up to 9000. Ringing indeed becomes prominent as the acceleration time falls down towards and below the ringing period.

Thanks. When the acceleration time is exactly the same as the ringing period, then ringing should almost disappear. But this point may be difficult to find unless you know the ringing period accurately.

Phaedrux

@dc42 I tried your steps from this thread

Try this:

Measure the distance between peaks in mm. If the bed background is 10mm squares then it looks to me to be around 2.5mm.

Divide that distance by the speed in mm/sec at which you are printing the perimeters. This will give you the ringing period in seconds. For example, if the perimeter print speed is 50mm/sec and the ringing distance is 2.5mm, that's (2.5/50) = 0.05 seconds.

Set the XY acceleration during printing (M204 P parameter) according to this formula:

a = (perimeter_speed - XY_jerk) / ringing_period

where perimeter_speed and XY_jerk are measure in mm/sec. For example, using the above figures and assuming jerk is 10mm/sec (e.g. X600 Y600 in M566), then a = (50 - 10)/0.05 = 800 mm/sec^2.

Alternatively, set the XY acceleration to one half, one third or one quarter of this figure.

It appears to work well and was able to quickly reduce some ringing artifacts at lower layer heights.

However, on my coreXY, I get slightly different ringing periods on the X and Y. M204 Pnnnn is a catch all for all move types. Is it better to use M201 Xnnn Ynnn instead and tune for each axis? Wouldn't that also limit travel acceleration?

I also went and created an Excel table that will help calculate the new accel value. Ringing Calculator.xlsx

wilriker

@phaedrux M201 is global maximum acceleration. So if you lower this the printer will in no case ever exceed this accel.

dc42

@phaedrux said in Periodicity of ringing:

@dc42 I tried your steps from this thread
...
It appears to work well and was able to quickly reduce some ringing artifacts at lower layer heights.

However, on my coreXY, I get slightly different ringing periods on the X and Y. M204 Pnnnn is a catch all for all move types. Is it better to use M201 Xnnn Ynnn instead and tune for each axis? Wouldn't that also limit travel acceleration?

Yes, that would limit travel acceleration too. I could extend M204 to allow separate X and Y accelerations, however I would rather introduce a new GCode to specify the rigning frequencies that need to be avoided. Also, a diagonal move will excite ringing on both axis directions.

I also went and created an Excel table that will help calculate the new accel value. Ringing Calculator.xlsx

Thanks!

Phaedrux

@dc42 So is the idea to profile your system and identify acceleration values that elicit ringing and avoid them? In my testing so far the formula has worked, however it also appears to lead to some further ringing in other areas of the print. For instance, I can remove the ringing from the corners where long edges meet, but a short edge meeting a long edge will excite a different ringing period because it didn't get up to the same top speed. Add to that different ringing periods for X and Y and it's hard to imagine finding a single acceleration value that would work for the entire print. That said from what I've seen so far it's very promising and I have been able to find some values that work most of the time.

dc42

What I have in mind for a future firmware release is to adjust the acceleration dynamically to avoid a specific ringing frequency. Where there are different X and Y ringing frequencies, diagonal acceleration/deceleration will excite both. It's probably best to adjust the acceleration to avoid exiting the ringing at the lower frequency. There will be some ringing at the higher frequency.

You could add mass to reduce the lower ringing frequency to one half of the higher ringing frequency. Then cancelling the lower frequency will also cancel the higher one.

dragonn

So the ultimate solution would be to put an accelerometer in the extruder carriage which would allow too do a self calibration of ringing?

Yeah I know this would require a lot of research and math. I'm just throwing an idea based on my limited knowledge of such things.

dc42

@dragonn said in Periodicity of ringing:

So the ultimate solution would be to put an accelerometer in the extruder carriage which would allow too do a self calibration of ringing?

Yeah I know this would require a lot of research and math. I'm just throwing an idea based on my limited knowledge of such things.

Yes, that would be a good solution for calibration, although it doesn't get around the issue of different ringing frequencies for the X and Y axes.

I'm putting together a spreadsheet to help predict ringing frequencies based on belt and motor specifications and the mass being moved, but I may not have time to complete and test it for a little while.