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.

[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.