GRBL rough acceleration profile

[Limbo68]

Hi, I finally updated my mach3 parallel port based CNC router to the modern age: Added Teensy4.1 with default settings 4 axis FW from the web builder. Now using gsender and all works fine, however: During the start and stop accelerations the machine is not nearly as smooth as via mach3. I cannot achieve the same accelerations and max speeds as via mach3 and the parallel port of a stone-age windows 7 desktop PC, have to set them at least 2-3x lower to not loose steps?

To investage what is happening I built a small frequency-to-voltage converter circuit to monitor the step pulse train. I have Vmax = 5000mm/min, accel = 1000mm/s2. With 100 steps/mm this equals 8.3kHz pulses at Vmax, giving around 35V at the output of the F/V converter. The attached pictures show the filtered (2nd order LPF @ 250Hz) curves for mach3 PP and teensy output. It is clear that mach 3 ramps smoothly and GRBLHAL in discrete jumps with 10ms update rate. Is this expected behavior and is there anything i can do to smooth this out?

[karoria]

Try increasing ACCELERATION_TICKS_PER_SECOND in config.h. As you use teensy4.1, you can go higher value. Be cautious as it consumes more hardware resources.

[Limbo68]

I have not mastered how to do a full compile yet, so i am unfortunatley limited to web builder generated FW for now. But will dive into it! Meanwhile, in the web builder there is a setting for ACCELERATION_TICKS_PER_SECOND which is greyed out unless you select "s-curve". I played a bit with this S-curve but it gives a whole set of new issues. While at 200 ticks per second all is smooth when jogging from gsender ($J=G21 G91 X10 F5000) it behaves differently for G00 and G01 movements. I get an increasingly long "tail" in the deceleration after multiple fast moves. Also short moves sometimes go wrong during acceleration. I found no combination of accel and jerk that solves this. Is it possible to have this ACCELERATION_TICKS_PER_SECOND button operational in web builder without selecting s-curve? Honestly I think that S-curves would be great, but there would me more performance gain in smoothing these "quantized" velocity steps during acceleration in grblHAL to start with.

[karoria]

I have not used web builder but you can try selecting with s-curve and increased acceleration ticks. Once flashed, search for $ setting which can disable s-curve/jerk acceleration. Then see if it helps. I am not sure if any such setting is there but you can list all available settings with $ES which may help you. Once you find a setting number $n, you can get more details about that setting using $$=n. I hope it helps.

Regarding that S-curve feature, it is still under primary development. So don't use it. Prolonged deceleration is known bug for that.

Cheers!
Ravi

[terjeio]

I have changed the Web Builder to allow selecting accel. tics/s without enabling jerk.

Once flashed, search for $ setting which can disable s-curve/jerk acceleration.

There is no such setting, it is a compile time option.

[Limbo68]

Thanks for making this option available Terjeio, it is much smoother indeed.

I settled at 300 ticks per second, higher values did not make a difference. The machine is still a bit noisier than before, mostly during Z moves. I guess there is some mechanical resonance that gets triggered due to a sudden velocity change (maybe stepper initial speed?). I can live with this and will use the machine for some time to see how it behaves.

A last question: is this higher velocity update rate active in all moves? At a conservative acceleration setting the machine ran different test files (with G00 and G01) reliably but in one occasion stalled the y axis when gsender ran a detailed outline of the job. I’m curious because I noticed earlier with s-curve testing that jogging via gsender (G91) was not affected by different $80x settings, while G00 and G01 are.

[Bartekn86]

Is it possible to add a Segment Buffer size to the webbuilder configuration? And does it make sense to increase this buffer size with higher ticks per second?

[terjeio]

A last question: is this higher velocity update rate active in all moves?

Yes.

I’m curious because I noticed earlier with s-curve testing that jogging via gsender (G91) was not affected by different $80x settings, while G00 and G01 are.

I recently added automatic disable of jerk when jogging and probing due to the long tail deceleration issue reported was mainly for jogging. When I did this I spent a fair amount of time trying to understand why the acceleration and deceleration part of the profile is asymmetric, but did not come to a conclusion other that it might be due to breaking them up in discrete steps. When I get more time I will look into this again, or if someone with better grasp of the math will give it a try I am all ears.

Is it possible to add a Segment Buffer size to the webbuilder configuration?

It is but I rather not do it, IMO it would be better to somehow adjust it automatically. See below.

And does it make sense to increase this buffer size with higher ticks per second?

I did try this some years back, and I could not see any difference in performance. It is there to feed the steppers when there is work going on in the foreground. What could be interesting to know is the max. time between calls to fill the buffer - simple logging could reveal that. If this is longer than the time it takes to empty the buffer it should be increased. I would be surprised if the max. time between calls exceeds a few milliseconds. To check this it would be best to do it on the slowest supported MCU with options like SD card and ethernet enabled - and running gcode programs containg a lot of short motion commands (e.g. laser engraving).
Note that the segment buffer could still be exhausted if the forground process is not able to keep the planner buffer filled, e.g. due to insufficient communication bandwidth to the sender or the sender not sending data fast enough.

[Limbo68]

Thanks for your help Terjeio! At least now i understand why jogging behaved differently from running a file during my tests..

Note sure if it brings something helpful, but during the S-curve testing i noticed that in a zigzag pocket the tail became more and more prolongued (or slower) in each subsequent (long) move. Almost as if some calculated number used in the previous move remains present in the calculations for the new moves. Only the long moves where you reach full speed had this tail. The first few (e.g 5) were fine and then it started to become slower and slower.

[XYartlab]

In the S-curve, I also found the aforementioned issue. I did not find any pattern of deceleration slowing down. Ultimately, I chose to increase jerk to improve it.