Periodicity of ringing

[dc42]

Question about what you're calling the "period of the ringing". You say to measure the period in mm (so the wavelength) and divide by the print speed, however, the speed is ramping up due to the acceleration. I'm not sure what you're after here.

Ignore the start of the ringing close to the corner, because the print head is accelerating there. Measure the wavelength a few mm form the corner, where the constant-speed phase will have started.

Looking at the rows in the Y ringing table where you put 'x' in the wavelength column because the ringing wasn't measurable, the acceleration times in milliseconds are:

67, 92, 44, 61, 21, 46

These are mostly close to multiples of 24ms, the ringing period that you measured.

What jerk setting are you using? Large values of jerk are likely to affect the degree to which ringing is cancelled by making acceleration time a multiple of the ringing period.

[burtoogle]

@burtoogle said in Periodicity of ringing:

Tomorrow I shall print some parts that previously have shown that low frequency ringing and see if they are now free of it.

I printed a part that normally shows the low frequency ringing with weight added to the top of the delta frame and the result is definitely improved. The wavelength of the ringing has increased and the amplitude has reduced so that it's now hard to see or feel the bumps. This photo just about shows the difference:

Still plenty of the high frequency ringing (hoping that David's new firmware additions may help with that).

[T3P3Tony]

To help measure the periodicity accurately would it be possible to design a test piece with inset lines at the bottom with varying periods and then look to see which period matched the ringing? Similar to the prints to line up the two independent heads on an Idex.

[JoergS5]

@t3p3tony I thought about something similar yesterday analogue to this:
https://www.thingiverse.com/thing:2040624
A calibration piece everyone can use to help analyzing, including different printer types.

Another idea is to use 0.1 mm nozzles and/or underextrusion, this should make the ringing easier to detect.

[T3P3Tony]

@joergs5 yes something like that would be good.

0.1mm nozzles are apparently very challenging to print with!

[kuhnikuehnast]

Just tried to generate a GCode like @mrehorstdmd did and implement different accelerations. I used the command "M201 X1500 Y1500". Is this right or should I use M204 instead?
I am a littlebit confused as the print looks almost the same after an ACC change and at an ACC of 3500 the requested speed was 150 mm/s but the top speed reached was only 137 mm/s (the length of the cube was 50 mm...? )

[dc42]

@kuhnikuehnast said in Periodicity of ringing:

Just tried to generate a GCode like @mrehorstdmd did and implement different accelerations. I used the command "M201 X1500 Y1500". Is this right or should I use M204 instead?

You can do it either way.

I am a littlebit confused as the print looks almost the same after an ACC change and at an ACC of 3500 the requested speed was 150 mm/s but the top speed reached was only 137 mm/s (the length of the cube was 50 mm...? )

Let's say you have jerk set to 10mm/sec. The distance available for acceleration and deceleration is 25mm each, so from v^2 = u^2 + 2as we have:

v^2 = 10^2 + 2 * 1500 * 25 = 75100

So v = 274mm/sec. IOW, even with acceleration reduced to 1500mm/sec you should be able to reach a top speed of 274mm/sec. So I suspect your slicer is reducing the speed, or you have lower M203 limits set.

[kuhnikuehnast]

This is really strange! I own a CoreXY and a Cartesian printer, both on DuetWifis. The Settings for jerk, Acc and max. Speed are on both machines the same (on the CoreXY for ACC in config.g even a littlebit higher 1026 vs 1300 on X and Y). I sliced 2 GCodes (Cartesian and CoreXY) and except the "standard parameters" (e. g. bed size...) both GCodes look exactly the same. (Speed Change every 25 layers, ACC Change every 75 layers). On the cartesian the Top Speed of 150 mm/s is reached but not on the CoreXY (if 100 mm/s or 50 mm/s are requested, then it works on both machines)... Also it seems like the ACC changes in the G-Code aren't applied by the board, as the print looks exactly the same even with an ACC of 3500 on the CoreXY???

Here the settings for both printers:
M566 X900 Y900 Z18 E120 ; Set maximum instantaneous speed changes (mm/min)
M203 X18000 Y18000 Z1002 E6000 ; Set maximum speeds (mm/min)
M201 X1026 Y1026 Z250 E120 ; Set accelerations (mm/s^2)

Here a segment of the GCode:

; layer 376 - ACC-Change
M201 X3000 Y3000
; layer 376, Z = 75.240
G92 E0
G1 X184.800 Y135.200 Z75.040 E1.6497 F3000
G1 X184.800 Y184.800 Z75.090 E3.2994
G1 X135.200 Y184.800 Z75.140 E4.9491
G1 X135.200 Y135.200 Z75.190 E6.5988

; process 851 - 150 mm/s
; layer 426, Z = 85.240
G92 E0
G1 X184.800 Y135.200 Z85.040 E1.6497 F9000
G1 X184.800 Y184.800 Z85.090 E3.2994
G1 X135.200 Y184.800 Z85.140 E4.9491
G1 X135.200 Y135.200 Z85.190 E6.5988

[dc42]

Your extruder acceleration limit is very low (E120 in M201) and that may be limiting the acceleration of printing moves.

[kuhnikuehnast]

@dc42 said in Periodicity of ringing:

Your extruder acceleration limit is very low (E120 in M201) and that may be limiting the acceleration of printing moves.

this is due to the use of the Nimble. But I use a Nimble on both machines with really exactly the same settings? On the cartesian with 2902 steps / mm on the extruder and with 2798 steps on the CoreXY. So if the extruder would be the problem, it would rather be the CoreXY that would reach the speed and not the Cartesian with more steps/mm???

[kuhnikuehnast]

Is there any chance to calculate the max Acc possible concerning all settings? (E-Steps / E-Acc /Acc on axis etc) this would maybe help me to figure out the ACC that is used while Ringing occurs.

[dc42]

@kuhnikuehnast said in Periodicity of ringing:

Is there any chance to calculate the max Acc possible concerning all settings? (E-Steps / E-Acc /Acc on axis etc) this would maybe help me to figure out the ACC that is used while Ringing occurs.

I have an experimental build that adjusts the acceleration dynamically to try to avoid exciting ringing at one specific frequency. So if you can measure the ringing frequency (which I described how to do earlier), you could try it out if you like.

[burtoogle]

@dc42 said in Periodicity of ringing:

I have an experimental build that adjusts the acceleration dynamically to try to avoid exciting ringing at one specific frequency. So if you can measure the ringing frequency (which I described how to do earlier), you could try it out if you like.

Great, I'm keen to try that out on my Kosell XL.

[kuhnikuehnast]

@dc42 said in Periodicity of ringing:

@kuhnikuehnast said in Periodicity of ringing:

Is there any chance to calculate the max Acc possible concerning all settings? (E-Steps / E-Acc /Acc on axis etc) this would maybe help me to figure out the ACC that is used while Ringing occurs.

I have an experimental build that adjusts the acceleration dynamically to try to avoid exciting ringing at one specific frequency. So if you can measure the ringing frequency (which I described how to do earlier), you could try it out if you like.

My problem is, that I can't calculate the period of ringing as I don't know the exact speed... (requested speed is 150mm/s top speed shown on the web interface ~137.4 mm/s)

I printed a 5 cm square in vase mode. Every 5 mm the print speed changed from 50 - 100 - 150 mm/s. And every 3 speed changes were tested with different ACC- values. (M201 from 500 at the start up to 3500 at the top (always +500)). But the print looks pretty the same for all ACC- values (I thought at least that it would end as spaghetti with a ACC-value of 3500) ..

I already tried to insert a M117 command that tells me the actual ACC (to test whether the g-code really changes the ACC-value) but this is also impossible

[dc42]

@kuhnikuehnast said in Periodicity of ringing:

I already tried to insert a M117 command that tells me the actual ACC (to test whether the g-code really changes the ACC-value) but this is also impossible

You can insert a M201 command without parameters, that should echo the current values to the GCode console.

The ripples on your photo look to me to have constant pitch and not fade away from the corner. So I suspect they are caused by belts, not ringing. [Edit: although they don't line up perfectly, which seems odd.]

[timcurtis67]

@dc42 said in Periodicity of ringing:

@kuhnikuehnast said in Periodicity of ringing:

I already tried to insert a M117 command that tells me the actual ACC (to test whether the g-code really changes the ACC-value) but this is also impossible

You can insert a M201 command without parameters, that should echo the current values to the GCode console.

The ripples on your photo look to me to have constant pitch and not fade away from the corner. So I suspect they are caused by belts, not ringing. [Edit: although they don't line up perfectly, which seems odd.]

They probably don't line up due to mechanical backlash in the axis? Maybe the head goes back and forth?

[dc42]

I have now released firmware 2.02beta1 which includes an experimental Dynamic Acceleration Adjustment feature. So if you measure the frequency of the ringing (see earlier posts) you can now use M593 to feed that value into the firmware and have it calculate the optimum acceleration on every move. Any acceleration limits you set using M201 and M204 will still be honoured; so if your slicer generates M204 commands to limit acceleration, make sure that the limits configured in the slicer are not too low.

[burtoogle]

Hi David, that's great news. I have installed the release and will be doing some test prints this morning. Thanks!

[Phaedrux]

This is great. Can't wait to try it out.

https://duet3d.dozuki.com/Wiki/GCode#Section_M593_Configure_Dynamic_Acceleration_Adjustment

[RCarlyle]

I like this idea a lot. Need to play with it a bit. I just put a Duet in a Cartesian printer for the first time so I'll have a good platform to try some things.

I'll review the math in the resonant frequency calculator as soon as I get a chance; I've been doing some similar work for my book on the motor side of things that should be relevant. Have you considered adding rod flex? This is typically small for i3 type machines but can be large for XY gantry machines when printing near bed center.

If we're going to go so far as to calculate elasticities and measure oscillation periods and such, the next obvious step to my thinking is to put some model-based feed-forward action into the corner jerk to cancel out the elasticity overshoot due to the velocity jump. Basically you'd fire off a few reverse-direction microsteps when you get to the corner to "wind up" the motor and belt elasticity to apply high force at the velocity jump. Then undo those microsteps to "unwind" the jerk force as the printer accelerates into the next segment.

If you know the moving mass, elasticity, motor torque, etc you can mode-shape the commanded motions to cancel out all the overshoot/ringing. (Or just use an accelerometer and measure it directly.) Which should provide crisper corners.