Periodicity of ringing

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.

dragonn

@dc42 you could make different moves to stimulate ringing on x separate from y and vice versa. On a cartesian/CoreXY this would be just moving axes separately during the calibration.

dc42

@dragonn said in Periodicity of ringing:

@dc42 you could make different moves to stimulate ringing on x separate from y and vice versa. On a cartesian/CoreXY this would be just moving axes separately during the calibration.

Yes, but that wouldn't help with the fact that if the ringing frequencies are different, then eliminating both of them may require a very low acceleration.

Phaedrux

@dc42 how exact does the acceleration have to be to get the ringing to go away?

On a test I measured the different ringing periods of x and y and it turned out that for x it was 2000ish and for y it was 1000ish. Half of 2000 is 1000. So I thought great, 1000 should get rid of both. But it didn't really workout. Now the values weren't exactly 2000 and 1000 but were within a couple hundred. Is that just too wide a margin?

And how accurate do you have to be on measuring the distance? Using calipers and a magnifying glass I think I'm probably as accurate as I can get.

dc42

I suggest you set the acceleration so that the deceleration time when decelerating from moves at perimeter printing speed is a multiple of 1ms, the period of the lower of your two ringing frequencies. Because your ringing period is low, you may want to make the deceleration time a small multiple of the ringing period instead of setting it equal to the ringing period.

You could try printing a test tower (e.g. a cuboid in vase mode) and change the printing acceleration at various heights using M204. This is on my list to do to test the theory that I worked out while on vacation, but I am too busy with other things right now.

kraegar

@dc42 said in Periodicity of ringing:

I suggest you set the acceleration so that the deceleration time when decelerating from moves at perimeter printing speed is a multiple of 1ms, the period of the lower of your two ringing frequencies. Because your ringing period is low, you may want to make the deceleration time a small multiple of the ringing period instead of setting it equal to the ringing period.

You could try printing a test tower (e.g. a cuboid in vase mode) and change the printing acceleration at various heights using M204. This is on my list to do to test the theory that I worked out while on vacation, but I am too busy with other things right now.

You really know how to party it up while on vacation

dc42

I have put a preliminary version of my spreadsheet to calculate ringing frequencies at https://www.dropbox.com/s/rc1lf1ml82dfzr0/3D printer resonant frequencies.ods?dl=0. It attempts to calculate the ringing frequencies you can expect to have due to belt elasticity and motor elasticity. I don't promise that it is correct.

It should be straightforward to apply to Cartesian printers, although I should probably combine the motor and belt elasticities to calculate the overall ringing frequency.

For CoreXY printers it will be necessary to work out how the elasticities of the two belts combine. I haven't done that yet.

For delta printers, I expect there to be 3 resonant frequencies fairly close together, rather like the stretching modes of an ammonia molecule (see http://www.chemtube3d.com/vibrationsnh3.htm) except that instead of the rods stretching, the carriages will move up and down.

dc42

I finally found time to do some beer-sloshing tests to verify my calculations. You can see the results here:

I estimated the frequency of sloshing to be 5Hz, so when the acceleration or deceleration time is 200ms then the sloshing should be cancelled as far as possible. The acceleration for these tests was set at 1500mm/sec^2, so that corresponds to a speed change of (1500/5) = 300mm/sec = 18000mm/min. And sure enough, when the motion speed is set to around 18000mm/min the sloshing is almost absent! Increase the speed to 25000mm/min and it comes back.