Periodicity of ringing

[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.

[JoergS5]

@dc42 The result is quite impressive and thanks a lot that you spent such a great effort in the vacancy (every test one beer - drunken ... ? )

In 3d printing, the movement goes on with direction change, speed not ending in 0. So the new direction, if it is not 90°, will enhance or diminish the effect. A test with those combinations would be interesting also. If you produce sloshing at the end and go on with a specific acceleration in the new movement, this could cancel out the sloshing. You could even set acceleration types differently for x and y, depending on which axis produces the sloshing.

[dc42]

Yes, a new acceleration that happens immediately after a deceleration and is not at 90 degrees to it will modify the ringing produced by the deceleration. However, if both the deceleration time and the acceleration time are chosen independently to avoid exciting the ringing, it should still give good results. On a delta printer, the deceleration and acceleration will interact even if they are at 90 degrees, and working out the interaction would be complicated.