Periodicity of ringing

[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

[3dmntbighker]

Question for @dc42

Are there any plans to offer a "debug" DWI mode that is tailored to tuning? So once tuned you just flip a code switch and return to the normal interface.

[dc42]

@3dmntbighker said in Periodicity of ringing:

Question for @dc42

Are there any plans to offer a "debug" DWI mode that is tailored to tuning? So once tuned you just flip a code switch and return to the normal interface.

What did you have in mind for debug mode?

[3dmntbighker]

@dc42 I'll try to put some notes together and post back. I was just thinking in general there must be a lot of things you want to know during the build and tune process that isn't necessarily interesting once your into the "production" printing phase. If you do a mod or a hardware change you flip that switch to help adjust for the change. Some of us would probably never get to the production phase of course because we can't leave well enough alone

[dc42]

For anyone who was following this thread, there is an example of how the new Dynamic Acceleration Control in RRF 2.02 helps to reduce ringing at https://forum.duet3d.com/topic/8256/reprapfirmware-2-02rc7-available/21/