S-Curve - Jerk for Acceleration settings.

[Dietz0r]

I recently looked up the old thread for that from 2021 (bevore the repository move) and there was a discussion back then to add s-curve / jerk settings to grblhal.
Before i take a deep dive down this rabbit hole i just wanted to ask if this is still on the roadmap or if it is currently parked.

I think it would be pretty substantial to have access to both 2nd order and 3rd order movement planners.

Greetings
Dietz

[terjeio]

I have plenty on my plate so take the deep dive.
Both planner.c and stepper.c should be pluggable modules?
It would be nice if they could optionally be run on a separate core and/or a FPGA?

[Dietz0r]

It would be nice if they could optionally be run on a separate core and/or a FPGA?

This would indeed be cool and maybe even the way to go, but i'm afraid that's way beyond my skills.

But i've recently worked through the planner and stepper files to get a feel for it and started adapting it a bit.
Just wanted to share my thoughts and assumptions, so maybe someone can chime in if i'm not on the right track.

grblHAL, in my current understanding, works with 3 buffers.
First is the g-code character buffer which holds the code from the files or MDI
Then the planner loads that and transforms it into bufferblocks, including things as acceleration, nominals speeds, direction vectors and so on and holds those blocks in a buffer line.
The first of those blocks then gets checked out by the stepper.c file and converted into segments,
Segment length is determined by the ACCELERATION_TICKS_PER_SECOND setting, which when left at the defaul value (100), comes down to a maximumg of 10ms per segment.
The segment buffer holds around 30-40ms worth of steps and gets replenished as it gets used. As long as the steps are not checked out by the stepper interrupt they can also still get modified by the planner.

My current approach is to adjust the acceleration that the planner uses to calculate entry/exit speeds to include the extra time needed for ramp up / down of the acceleration. So it can continue to operate in trapezoid mode, while the checked out segments acutally apply the jerk to the curve.

Any thoughts on that?

[TheRealBeef]

I am watching with great interest, although I'm not so familiar with GRBLHal just yet.

Of course we have a bit different implementation for LinuxCNC that I'm working on with Grotius. There's quite a few ways to tackle this particular problem - none of them particularly easy.

I think that the two simplest methods involve bringing an external library to do the jerk calculations for you - basically just removing the existing trapezoidal planner and using this tool to calculate your trajectories (and you can keep the existing path planning code and just pass the commanded positions and the relevant vel/acc/jerk limits to it and get your results back) or to just take the existing phases that the trapezoidal motion planner is using and subdivide them into more phases to include increasing/decreasing acceleration on each end.

We're of course taking the first option with our approach, passing everything to Ruckig in a single DOF and getting the results back.

[EmpyreanCNC]

@terjeio I’m helping Dietz0r with getting this tested on a servo machine. We’ve managed to get a firmware compiled and flashed onto the teensy I’m using. The new settings are appearing where they should be(per axis) but they aren’t being populated with the defaults set in settings.c in addition when we try to write a new value to them it doesn’t take. Switching to console and using $$ you can see the value is staying at 0. Is there anything you can think of that might be causing this and would give us an avenue to investigate?

[terjeio]

Change Setting_IsExtended to Setting_IsExtendedFn in the definition since the underlying data is read/written via functions. And add handling of the settings in set_axis_setting() and get_float().

[EmpyreanCNC]

That has worked wonderfully thank you! Will report back how it goes on physical testing tomorrow

[Dietz0r]

yep! thanks for the clue! found out the get_float only checked for the lower axis setting numbers (100-199) and i shoved the jerk into 22X ... i modified the if statement and now it's showing up

[madman-011235813]

I am VERY interested to hear how the testing is going with this. I have a large CNC machine and could use the jerk control feature to smooth out the movements. Is the change that you're making compatible with stepper motors as well?

I'd also be happy to test any stable changes.

BTW, I'm also an embedded firmware developer with 25+ experience who also happens to be using the RT1062 MCU in a project at work. I might also be able to assist with the development of this feature.

[Dietz0r]

Hey,
at the moment it's a very simple constant jerk implementation, that is actually able to run and produces the wanted results. And yes it is compatible with steppers. I just changed the segment generator to ramp up the acceleration by the max allowed jerk over the timeframe of the segment.

If you want to help you're gladly welcome, you can find the current repo here.

[Dietz0r]

Just a little update on the progress.
Here are two comparison videos:

Feed: 10000mm/m , Accel: 5000mm/s² for both.
Normal Trapezoidal:

Trapezoidal.mov

and with 50000 mm/s³ constant jerk:

ConstantJerk.mov

You can hear it being way smoother in the corners and on direction changes. It's not almost slamming to a full stop.
Finally, here it is actually milling with Feed: 1400mm/min Accel: 3000mm/s² and Jerk: 60000mm/s³.

Jerk-Milling.mov

The left part was done with the tradition trapezoidal and the right with jerk. There's already a noticably improved surface finish.

MillingResultJerk.mov

Big thanks to @EmpyreanCNC willing to also run beta software and providing debug help and the videos. :)

Cheers! :)

[TheRealBeef]

This is the appropriate way to approach it at this stage, otherwise a separate branch is also reasonable.

[Dietz0r]

I will accept a PR only if the new functionality can be enabled by a compile time option (new code guarded by #if ... #endif). This way the change can get more exposure without the risk of creating issues for those who need a stable version. Later, when the new code has proved itself, the code guards can be removed.

not a problem. i've already gone through the code and encapsulated it with #if #endif clauses :)

[karoria]

Waiting for merge...

[madman-011235813]

@Dietz0r , forgive me for asking what might be a very basic question about how to manage the source code to test your feature, but this is the first time that I will be building and testing grblHAL code that isn't from the main branch of the original grblHAL repo.

Should I recursively clone the original submodule for the iMXRT1062 (which clones the original core and other components) and then clone (copy) your core over top of that? After that, I presume I follow the original instructions in the README for the iMXRT1062.

Does this sound right?

[terjeio]

Should I recursively clone the original submodule for the iMXRT1062 (which clones the original core and other components) and then clone (copy) your core over top of that?

Correct, this is the way to do it for now.

[whmountains]

What's the status on this?

[Dietz0r]

Hey, it's currently sitting there on my github repo's in a semi tested state. It has done some work on Empyreans and my machine and some others from the PrintNC community have tested it. If you want to test it too, the modded core is available.

There's been a few reports of it not working nicely with continious jogging commands from ioSender but i didnt have any time in the last few month to track that down. (And frankly dont know if i'm able to.) So this is a known issue and why i didnt push it to @terjeio yet.

[whmountains]

Thanks for the info! I might try it out. It's nice to know where this stands.

[axxel]

I've been eagerly trying out the current version (used the web builder to compile for an rp2040) but soon enough ran into the issue that after some random sequence of jogging, the machine seemed to virtually stop moving or rather come to a complete crawl. My gSender felt like it "hang" and hitting the "stop jogging motion" button did not change anything either. My settings were something like Feed: 3000mm/m , Accel: 400mm/s², Jerk: 4000mm/s³.

This made me immediately revert the firmware as it functionally 'broke' my machine. Is this what was originally referred to here? Is there something I could do to fix my problem?

[terjeio]

I think this is due to a/some step segments having very long step interval(s). On a few occasions I had that happening during development with regular acceleration and I "fixed" that by capping the max step interval to around 2 seconds in the driver. IMO the jerk acceleration profile is likely to make this happen more often and also for more step segments than regular acceleration.
That cancelling a jog does not work is due to cancel only stop filling the segment buffer, if there are step segments pending with long intervals these has to be completed before the halt can be executed. And the tail end of deceleration for the halt may also be affected...

I have not managed to replicate this behaviour yet - IMO since there are many factors that has to coincide to make it happen, the final one might be the finite precision of float calculations.
It would be helpful if I can get all the stepper settings and jog settings (feed rate and distance) when this happens. And if possible, leave the machine crawling for a while to see if it stops by itself and if the move is then within the distance commanded by the jog. If so then it is higly likely that overly long step interval is the cause.

[0727fqh]

Hi, thank you for your change, I hope my machine can also use it, so I changed it in the project of bdring/Grbl_Esp32, but unfortunately the change did not succeed, and the machine did not work properly. I modified my code according to the macro definition of ENABLE_JERK_ACCELERATION. Is it possible that Grbl_Esp32 is not compatible with grblHal? I would love to hear from you

[Dietz0r]

Hey, yeah Grbl_ESP32 is a different grbl port and not at all compatible with the grblhal firmwares.
Though grblhal has a ESP32 driver so you could switch over.

[0727fqh]

Thank you for your suggestion, because now our company has been using this Grbl_ESP32 project in a large number, switching may be more troublesome, I will check the difference between the code, in addition, I don't quite understand the acceleration Jerk in your video: 60000mm/s³, do you need to set this parameter to this large, the default is 100

[Dietz0r]

I don't quite understand the acceleration Jerk in your video: 60000mm/s³, do you need to set this parameter to this large, the default is 100

This is not the normal acceleration but an additional setting to describe third order motion. It smoothes out the sudden acceleration at the start and end of the programmed motion pathes enabling smoother and usually higher end accelerations because it eases the motor into the motion instead of slamming against the inertia of the system with full force.

Here's a graph explaning it:

[0727fqh]

Ok, thanks for the diagram, I'll keep trying

[karoria]

Hello friends,
Is it now implemented in master? If not, any wiki to change and compile the code to implement it? Thanks in advance for any guidance on this.
Cheers
Ravi

[distebia]

Hi, to compile grblhal activating jerk profiles do I always have to clone -recurse the imxrt1062 driver and replace the core with core/jerk? Or can I activate the option from the driver and everything proceeds automatically? Also does it work only for teensy or also for esp32?

[Dietz0r]

Hi, to compile grblhal activating jerk profiles do I always have to clone -recurse the imxrt1062 driver and replace the core with core/jerk? Or can I activate the option from the driver and everything proceeds automatically? Also does it work only for teensy or also for esp32?

I think we have all the major kinks ironed out right now and terje is testing for robustness and maybe adjusting some things internally. so if you wait until the pull request is through you will just have to enable it from the config.h file and will compile for any driver.

you may need to look out how computational intensive it is, the teensy has a lot of cpu in comparison to some of the smaller chips.

[distebia]

ok, grazie...attualmente sto costruendo una corexy con teensy e laser co2...ancora sono a niente ma vorrei anche provare i profili jerk

[terjeio]

All drivers now updated with the modified core, also available from the Web Builder in the Advanced features tab. The info button in the Web Builder links back here, a Wiki page for the options should be created and linked to instead?

[Dietz0r]

All drivers now updated with the modified core, also available from the Web Builder in the Advanced features tab. The info button in the Web Builder links back here, a Wiki page for the options should be created and linked to instead?

Thank you for all the work!
Also have a great new years eve and see you next year! :)

[itchytweed]

Just ran across this thread. The idea of adding S-Curve/JERK is a laudable pursuit. No machine can instantly accel/decel because of inertia. Using s-curve compensates for this by easing into the motion rather than slamming into motion the way trapezoidal motion works. There are added benefits as well: lower instantaneous current demands; less stress to motion parts/equipment; cleaner cuts without oscillations on movement transitions. Use of s-curve/jerk was very popular in usage by me, having retired from the industrial engineering/motion control fields, to make everything work longer and control machine abuse especially with high inertia loads. BTW, the diagram that Dietz0r put up is a good study of the subject. Now to leave this on a interesting note, you have velocity, acceleration, jerk, snap, crackle, and pop. Here is an interesting article if you care to dive into this and get a headache - https://en.wikipedia.org/wiki/Fourth,_fifth,_and_sixth_derivatives_of_position

Happy New Year!

[Dietz0r]

lower instantaneous current demands; less stress to motion parts/equipment; cleaner cuts without oscillations on movement transitions.

that's exactly why i'm trying to do this. we (me and all the peeps that you see randomly chime in here) are from the printNC community and are usually sitting right at or above the cusp where machinemass really starts to matter. we've also gotten a few folk right now building multi100kg UHPC monsters driven by grblhal boards so it seemed worthwhile to tackle it.

The current version in the core is very basic and has issues with slow speed states (like jogging) that i and a few others are currently working at, having it integrated into the core already gave very valuable feedback on parts to improve!

edit: happy new year to you all too! :)

[distebia]

personalemte sto costruendo un laser co2 su struttura core xy, teensy 4.1 e grblhal con jerk attivato...sulla carta dovrei fare incisioni di foto ad alta velocità e il jerk sembra arrivare al momento opportuno...solo che non so come regolarlo bene...magari avere una guida di partenza o valori consigliati sarebbe perfetto

[distebia]

oggi ho provato ad installare il firmware con jerk attivato su mks dlc32...ho alzato i valori $800 e $801 da 100 fino a 60000 ma non ottenevo un movimento regolare. $110 e $111 sono 30000, $120 e $121 sono 3000...se disegno un quadrato e lo eseguo a 30000 parte a scatto per il primo tratto (70% del lato) per poi andare pianissimo nel restante tratto, stessa cosa per gli altri 3 lati...non so...forse è la scheda lenta e quindi non adatta a questa implementazione? e poi...avere un punto di partenza ed affinare le impostazioni?

[Dietz0r]

Ehi, sembra proprio il bug su cui sto ancora lavorando. Il calcolo dell'accelerazione effettiva non è stato ancora ottimizzato per valori di strappo più piccoli. Altrimenti ricordatevi sempre che questo è ancora in versione beta. Grazie mille :)

[Dietz0r]

Ora riprova con il nuovo codice migliorato, i movimenti dovrebbero essere molto più fluidi. I buoni valori dovrebbero iniziare da qualche parte con un'accelerazione superiore a x10. Puoi anche provare a regolare un po' "acceleration_ticks_per_second". Quindi forse aumentare leggermente la dimensione del buffer.

[distebia]

ciao, grazie...ho compilato con il jerk attivo e sembra funzionare...sto testando su mks dlc32 con driver dvr8825 e nema 17...corexy su guide lineari mgn09...$110 e $111 sono 50000, $120 e $121 sono 10000, $800 e $801 sono 50000....la macchina va, prima con accelerazioni di soli 5000 avevo troppe oscillazioni del telaio, ora sembra migliore...ma che valori mi consigli per la mia macchina mks? In costruzione ho una corexy co2 con teensy 4.1, dm556 e nema 23

[Dietz0r]

mi dispiace, non ho idea di quali impostazioni consigliare perché sono altamente individuali per la macchina che possiedi, quindi potresti dover sperimentare quali impostazioni ti daranno i migliori risultati. comunque sono felice che ora funzioni meglio! :)

[Dietz0r]

https://github.com/grblHAL/core/wiki/Jerk-acceleration

the initial checkin of the jerk acceleration wiki page is up, i'm still waiting on the pictures but the text is also helpfull :)
@terjeio i hope this is what you had in mind?

[terjeio]

Looks good, now linked in the Web Builder.
I am a bit unsure what to do about ACCELERATION_TICKS_PER_SECOND in the Web Builder, add a dropdown with some preconfigured values? And calculate the segment buffer size? What do you think?

[Dietz0r]

I think a dropdown with a few preconfigured values would be fine for the webbuilder. 100, 200, 400 and 500 maybe? anyone that wants more granular control or higher values really should be compiling from source anyways but it's nice to have the options as a starting point.

[terjeio]

I think a dropdown with a few preconfigured values would be fine for the webbuilder.

Dropdown added now, segment buffer size set according to selection. I'll leave it for those who will try it out to test/verify.

[MARIOBASZ]

this looks spectacular! I won't be able to turn the machine back on for three months, but I'm looking forward to seeing the advantages on trochoidal milling!

[Meliusja]

I got the latest version and built with Jerk enabled and ACCELERATION_TICKS_PER_SECOND=200. My mill is similar to a Tormach 1100 but a little heavier. I have max feed at 5000 accel at 500 and jerk at 25000. I like how it smooths the motion. But I think I have a problem already reported earlier. I noticed at the end of my program it does a long rapid move to go to G28 X and Y. When it stops it crawls the last little bit for maybe 5 to 10 seconds and then stops and everything is fine. I have not noticed this in the middle of a program execution yet but I have only done a few program executions. Any Ideas?

[Dietz0r]

Hey! Glad it's working nicely for you overall!

The issue you describe is the reported one, yeah. from our current understanding it's a slight mismatch between the jerk deceleration ramp and the position. It hit's the minimum speed slightly before hitting the programmed position (because of the quantized nature of the accel ramps) so it crawls along at the minimum acceleration/speed until it reaches the end position.
This is exacerbated in moves that go to planned stop (aka 0 end speed) but not noticeable while running a programm because you have some junction speed between programmed blocks in 99.9% of cases.

we"re currently looking into fixing that in different kind of ways and have a promising solution from @engigeer in testing :)

Dietz

[karoria]

Hi @Dietz0r
Thanks for all your efforts for jerk implementation in grblHAL. I have just compiled and flashed my custom board and table tested one AC servo axis. A quick observation is acceletation and deceleration takes different times. It looks like jerk parameters apply to acceleration but not to (or having less effect on) deceleration. Any clues on how to set them right? Do I need to alter any other parameters then $12x and $80x?

[karoria]

Hi All!
Now I am inn for jerk testing with my customised board with Teensy4.1. When compiling, if I increase Segment_buffer to anything more than 30 it doesn't compile at all. Following is compile time message:

teensy_size: FLASH: code:342596, data:85472, headers:9176 free for files:7689220
RAM1: variables:164928, code:339928, padding:20520 free for local variables:-1088
teensy_size: RAM2: variables:12384 free for malloc/new:511904
Error program exceeds memory space
*** [size] Error 255

and between 12 to 30, it compiles but breaks ethernet communication (the only means I connect to teensy) on my board. Acceleration Tick per Second value is kept default now (100). What can be the cause for this? I want to test jerk settings on my servo driven mill on which I can set aggressive acceleration, please suggest me what should be taken care of.
Cheers!
Ravi

[terjeio]

Ok, I have just pushed an update that executes some code from flash, and some data has been moved to DMAMEM.
I will later move some data in the core and plugins to DMAMEM.

@luc-github The display plugin should be changed to leave at least the font data in flash by prefixing the definitions with PROGMEM?

[luc-github]

Ok, I have just pushed an update that executes some code from flash, and some data has been moved to DMAMEM. I will later move some data in the core and plugins to DMAMEM.

@luc-github The display plugin should be changed to leave at least the font data in flash by prefixing the definitions with PROGMEM?

@terjeio it is already the case https://github.com/luc-github/plugin_oled_display/blob/main/fonts/oled_9.h#L47
https://github.com/luc-github/plugin_oled_display/blob/main/fonts/oled_11.h#L47

Or I misunderstood the question ?

[terjeio]

@luc-github - I am used to seeing the PROGMEM at the start of variable definitions, so overlooked it while quickly browsing through the code. Sorry for the noise.

[karoria]

Ok, I have just pushed an update that executes some code from flash, and some data has been moved to DMAMEM.
I will later move some data in the core and plugins to DMAMEM.

@terjeio Can you please point me to those changes? I have somehow mixed up the code and my teensy memory is still not available for extras. I want to double check whether I have really made that update. Sorry for asking this too basic thing due to my technical limitations.

[terjeio]

Here and here.