Periodicity of ringing

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

[jkdp]

200 jerk and 1050 accel got rid of the bulging corners for me

[burtoogle]

@jkdp said in Periodicity of ringing:

200 jerk and 1050 accel got rid of the bulging corners for me

Is that the X/Y or E values? Thanks.

[jkdp]

basically low accceel and high jerk

[burtoogle]

@jkdp said in Periodicity of ringing:

basically low accceel and high jerk

Is that the X/Y or E values? Thanks.

[jkdp]

M566 X1250 Y1250 Z78 E310 ; Set maximum instantaneous speed changes (mm/min)
M203 X15000 Y15000 Z160 E9000 ; Set maximum speeds (mm/min)
M201 X210 Y210 Z100 E2755