slight pause/hitch in motion at 15khz+ feed rates about grbl

[simen]

I'll have a look om the scope. Would it make sense that this could be
a harmonic property of your motors or general setup? Are you in a
position to test with a different motor unattached to any of the
mechanics just to rule that out?

On Sunday, June 5, 2011, dirktheeng
[email protected]
wrote:

Hi,

I am using grbl for a CNC laser project.  I just got the arduino hooked up and started playing around with the motion.  I noticed a slight problem when I set my feed rate high.  It seems to have an audible hitch in the motion as it accelerates to speed.  It does not seem to do it on deceleration.  I calculated the the pulse rate where the problem starts and it comes out to be really close to 15khz.  I'm not sure if I have a setting wrong somewhere, but it does it every time.  Have other people noticed this?  It doesn't seem to loose pulses as best as I can tell, so I am thinking that something is causing an interruption in the pulse train.  I am using pololu A4988's and the pulse width is set to 20 micro seconds in grbl.  There are about 81.7 pulses/mm and the acceleration is set to about 800 mm/s/s.  It doesn't do it below 15khz.

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/21

[dirktheeng]

I can give it a shot with a different motor. However, when I set the accelleration much higher, it seems to take noticeabley less time to accellerate than decelerate. I think it is jumping to a higher speed on acceleration instead of smoothly accelerating. I'll try plugging in a different motor when I get back from church.

The thing about sympathetic vipration is that you'ld expect it to hit the same frequency on the way down as on the way up and it doesn't make the noise on the way down.

I should also mention that the problem doesn't occur at 15kh speed, only when the feed rate is set above 15khz. I don't know the actual frequency where the hitch happens while it is accelerating, but it does it on any feed rate speed above 15khz. That is if I give a command g1x100f11000, it moves smoothly, but if I give a command g1x100f12000 or any f higher than that, it does it every time. the hitch occurs somewhere in the middle of the acceleration time. It also does not seem to matter what I set the acceleration to. I am surely not reaching the limit of the motor to cause a slip.

[dirktheeng]

I tried it out with a different axis and it does the same thing. the audible "hitch" definately occurs when the speed is set to above 15khz.

[simen]

Thanks! I'll have a look with the scope tonight. Which version are you
using? Prebuilt, self built from recent master branch or 'edge'?

On Sunday, June 5, 2011, dirktheeng
[email protected]
wrote:

I tried it out with a different axis and it does the same thing.  the audible "hitch" definately occurs when the speed is set to above 15khz.

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/21#comment_1305211

[simen]

Ah, could you just paste me a dump of your settings (type $ and enter)

On Sun, Jun 5, 2011 at 8:01 PM, Simen Svale Skogsrud [email protected] wrote:

Thanks! I'll have a look with the scope tonight. Which version are you
using? Prebuilt, self built from recent master branch or 'edge'?

On Sunday, June 5, 2011, dirktheeng
[email protected]
wrote:

I tried it out with a different axis and it does the same thing.  the audible "hitch" definately occurs when the speed is set to above 15khz.

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/21#comment_1305211

[simen]

I have tried now with both master and edge branch and I can't
reproduce your problem. The pulse train looks squeaky clean on the
logic analyzer. Also I am unable to reproduce your problem with the
settings record. Need your exact settings and g-code and also would
like to know exactly what kind of *duino you are using.

On Sun, Jun 5, 2011 at 8:32 PM, Simen Svale Skogsrud [email protected] wrote:

Ah, could you just paste me a dump of your settings (type $ and enter)

On Sun, Jun 5, 2011 at 8:01 PM, Simen Svale Skogsrud [email protected] wrote:

Thanks! I'll have a look with the scope tonight. Which version are you
using? Prebuilt, self built from recent master branch or 'edge'?

On Sunday, June 5, 2011, dirktheeng
[email protected]
wrote:

I tried it out with a different axis and it does the same thing.  the audible "hitch" definately occurs when the speed is set to above 15khz.

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/21#comment_1305211

[dirktheeng]

Here's the settings that can cause the problem
$0 = 157.738 (steps/mm x)
$1 = 157.738 (steps/mm y)
$2 = 157.738 (steps/mm z)
$3 = 15 (microseconds step pulse)
$4 = 14000.0 (mm/min default feed rate)
$5 = 14000.0 (mm/min default seek rate)
$6 = 0.100 (mm/arc segment)
$7 = 0 (step port invert mask. binary = 0)
$8 = 800.0 (acceleration in mm/sec^2)
$9 = 0.0 (max instant cornering speed change in delta mm/min)
'$x=value' to set parameter or just '$' to dump current settings

I wish I had a scope to check this out.

I am using the main trunk version. I copied the source code and built the hex using WinAvr and used the arduino uploader to get it on the chip.

How do I completely flash/format the chip and load it over again. I'm thinking there may be a problem with the way it loaded.

[dirktheeng]

when the acceleration is this low, you can definately tell that it accellerates quicker than it decelerates too. Can you send me wave forms from the acceleration and deceleration?

[dirktheeng]

I downloaded your build code and tried that, it does the same thing. i'm really hoping that my arduino isn't bad.

[chamnit]

Dirk, I think this is related to the long slope issue that stephanix has noted. I have run into the audible hitch as well. After testing a theory, I think this is coming from the difference between the exact integration solution used by the planner and the discrete de/ac-celeration performed by the stepper program. When I had cranked up the ACCELERATION_TICKS_PER_SECOND in the config.h (have to completely re-compile the code), the hitching steadily went away.

The grbl default is to update the acceleration 40 times a second. With your 800mm/sec^2 setting, you probably go through just one or two acceleration ticks before you reach nominal speed, and completely overshoot or undershoot the following speed change. By reducing the acceleration like you have, you basically are allowing grbl to perform more acceleration tick updates over that acceleration period. So the problem goes away or becomes less noticeable. By cranking up the ACCELERATION_TICKS_PER_SEC, you might be able keep your high 800mm/sec^2 acceleration and allow grbl to create more acceleration ticks over that acceleration. You'll likely have to find a sweet spot to allow grbl to run smoothly and not overload the CPU.

If you are having trouble with cranking up the parameters, I have re-written the planner code to be a lot more efficient and effective and I have gotten the ACCELERATION_TICKS_PER_SEC to 360L at 5kHz step frequencies. I haven't tried any faster, since these problems for me disappear around 120L. I'm currently looking to a way to efficiently fix this inherent problem by trying to find a better way to predict what the stepper program is doing in the planner estimations. But don't hold your breath. The Arduino CPU is pretty maxed out with grbl, and it'll be difficult to come up with a clean simple solution.

[chamnit]

Dirk. This is what I posted on stephanix's issue and I believe this is the solution to your problem as well.

---

OK. I have tracked down the main issue causing this problem. It's in the stepper.c and it has to do with how and when the de/ac-celerations are done. To fix it, I applied the midpoint rule for curve approximation (or timed it the start of the velocity changes a little differently) and made sure the stepper interrupt would alway stop and start the accelerations and decelerations exactly on time. Tested it on my mill and worked fantastic.

The other stop-gap solution with increasing the ACCELERATION_STEPS_PER_SECOND in the config.h still applies, especially for people running very high accelerations and feedrates.

Expect the code to be post sometime this weekend on my fork.