More questions about M593 dynamic acceleration and ringing
-
I hope I'm not beating a dead horse...
I just updated my firmware to the latest stable release (2.02) and added M593 to my config.g file.
The config.g looks like this:
M205 X10 Y10 Z0.2 E5 ; Set maximum instantaneous speed changes (mm/sec)
M203 X18000 Y18000 Z900 E3000 ; Set maximum speeds (mm/min)
M201 X3000 Y3000 Z1000 E3000 ; Set maximum accelerations (mm/s^2)
M204 P3000 T2000 ; Set print and travel acclerations (mm/s^2)I ran a single-walled test square print, 100 mm on a side, and set speed to 100 mm/sec. At acceleration of 3000 mm/sec, and 100 mm/sec print speed, the extruder will reach 100 mm/sec about 3 mm away from the corners, so I made my measurements starting about 10mm from the corner. I measured the wavelength of the ripple and calculated the frequency to be 27.6 Hz.
I added this after the M204 statement:
M593 F27.6
and then ran the print again and the result was identical to the print without the M593 statement.
Over how wide a bandwidth should the M593 adjustment provide some benefit?After reviewing the threads on it, I'm left with the impression that it's best to use high acceleration and low jerk when you use M593. Is that a reasonable approach? Can you suggest a jerk value to use as a starting point?
What would be the recommended tuning order if one is going to use pressure advance, nonlinear extrusion, and dynamic acceleration?
-
I've been meaning to do some testing myself.
I think your max acceleration may be set too low to allow dynamic acceleration control to work well, but I'm not sure. I use 6000 as the max, but usually have it limited by the slicer depending on the move type. Based on a recent comment from DC42 I think that might actually be hampering how DAA is working. It may be best practice to set the max acceleration high and prevent the slicer from modifying it, and let DAA manage the acceleration profile entirely. This would also mean not using M204 P T either.
Curious why your travel acceleration is set lower than your print acceleration. I would think you'd want the travel moves to complete as quickly as possible since it's a straight line move.
Your jerk setting is also quite close to mine. I find I get smoothest curves with 10-15mm/s, anything lower than that seems to cause too much of a pause at direction changes.
I've seen DC42 say that nonlinear extrusion should be tuned first. Unable to find the post now.
EDIT: Here it is https://forum.duet3d.com/topic/8537/pres-adv-or-non-lin-extrusion-what-to-calibrate-first/5
-
Firmware 2.02 will only reduce acceleration or deceleration if that shifts the first zero of the vibration spectrum on to the specified frequency. This happens approximately when the acceleration is equal to the speed times the frequency. This isn't exact because the jerk affects it too. So, based on your figures, if your acceleration is 3000mm/sec^2 then there should be a difference. But as your acceleration limit was already close to the optimum which is around 2760, the difference will be small.
In the 2.03beta firmware, if the acceleration limit is too low to shift the first zero to the ringing frequency, it will shift the second zero to the ringing frequency if that is possible.
-
What I'm about to suggest is not the answer that you are looking for, but I think we could use a better methodology and I think you will like a more technical approach.
IIRC your printer is in a makerspace, where you have different kinds of equipment. Maybe you have some some studio equipment that you could use to measure with precision the resonant frequencies. You just need to repeat the same test, giving that the test its good at exciting the resonant frequencies, with a good audio recording equipment, it needs to be good in the low pitches. The recorded noise will be a good estimation of the frequency response of the printer. This is used in CNC machines as a low cost vibration measuring setup, specially to manage chatter.
Using this setup and a sound reference, to calibrate the amplitude and get repetitive (but not accurate) result, you will be able to know the frequency and one estimation of the amplitude of the vibration, so you could measure more effectively the improvement of the vibration response. I know that we are really doing this to improve prints, but a methodological approach could explain some inconsistent results better, and lets be honest, the community is full of inconsistent results.
Of course, ideally this will need to be done with acelerometers, but this setup gives a lot more quantifiable data than the visual one and is still pretty simple. The downside is that the noise produced by the vibration maybe is not high enough, and well that you need to study the data, so its more work. But hey, consistent results usually saves time in the long run.
-
@kunok The printer is at home now, finally, after about 6 months at the makerspace, which is why I now have time to update firmware and run tests, and tweak. I can't ever seem to do anything at the makerspace except help other people fix their 3D printers/printing problems.
I have an accelerometer I can mount on the hot-end and have been thinking about using it to check the resonance spectrum. I'll give it a try and see what I get. I can record the output from the accelerometer and derive a spectrum using audacity (I think). I think it would be a lot better than trying to guess at measurements of the ripple on the prints.
-
@mrehorstdmd Just to note that using an accelerometer, analyzing and getting consistent results is far more difficult that just using a microphone, and I'm not sure if in this case the results would be more relevant.
But if you want to try anyway, I will look forward to your setup and results.Also if you are using acelerometers, get the resonant frequencies directly, you just need to use an impulse function, just hitting in this case the extruder with a small hammer or something similar.
About Audiacity, that was what I was thinking about but I'm not sure if it can be used that way, if I recall correctly we were using Matlab programs. Maybe you can check in Octave, the opensource alternative to Matlab
