LinuxCNC S-Curve Accelerations

Hi all,

Andy is right. i was working on a modified trajectory planner.

It took me a lot of time to figur things out.
Last year i had it partially working, but i was not satisfied. And i stopped with working on it.
Mayor issue was that lcnc is running out of cyclus time. The different algo's take to much.

@ZZ912,
It's not a private project, code is on github.

@Beef,
How is your project status?

I have another idea to make this a little easier. How about a custom Kinematic comp. I've been thinking about it for a long time but I can't implement it. The timers for the s-curve bell should be adjustable in the ini. and then just forward it in the comp.
E.g. "pos->tran.x = (j[0] s-curve algo);"

I have another idea to make this a little easier. How about a custom Kinematic comp.

Hm, not sure but basically you would be using a toolpath that has been generated on condition that the first derivative (velocity) is continuous and then you are just filtering the acceleration to make a new path that also satisfies the condition of having the second derivative continuous. Also you would be doing this in real time with zero look ahead. I don't think that is possible without considerable deviation from the part geometry but I'm no expert.
I've always though that this is a question of trajectory planning, which means: Jerk control is built into the _shape_ of the tool path like it is done in road building.
At the end of the day every toolpath run on a real machine is going to be jerk limited because no drive chain can accelerate instantly but if the toolpath has not been calculated with this in mind then there are going to be geometric errors because of this.
 

Mayor issue was that lcnc is running out of cyclus time. The different algo's take to much.

Note there is a thread about moving the trajectory planner to non-real time which may be of interest (If I recall correctly the code itself was unfortunately not shared):
forum.linuxcnc.org/38-general-linuxcnc-q...time?start=10#263611

@Grotius It's great to hear from you!

So I haven't been able to make much progress in the interim - I have competing demands with work and this is still a side-project for me. Not to mention it's a super complex problem to wrap your head around. To be honest I have absolutely no idea how you wrapped your head around it so quickly - I had a lot of respect for your work just reading the forum posts, and now that I see it firsthand I'm even more impressed with what you got working .

I was able to compile your existing code and get it to run but I wanted to be able to incorporate it into the existing LinuxCNC build system and make some changes to use a compiled Ruckig lib instead of the semi-custom library it appears you made.

The reason I want to try and use the compiled lib is that I also reached out to the Ruckig guys to see if they are willing to sell licenses for individuals/hobby use. I don't believe that the lookahead function will work without either some hacky workarounds such as adding extra axes and performing calculations incorporating those, so knowing whether or not this is an option would likely be helpful. I assume they will distribute precompiled binaries or something to that effect, which is why I want to try and rely on a compiled lib.

If they aren't willing to do individual licenses and there isn't a reliable way to make the lookahead function work, I may end up ditching the ruckig lib entirely and trying to incorporate one of the 3d printer S-curve trajectory planners instead to get it working for 3 axis stuff at least.

basically you would be using a toolpath that has been generated on condition that the first derivative (velocity) is continuous and then you are just filtering the acceleration to make a new path that also satisfies the condition of having the second derivative continuous. Also you would be doing this in real time with zero look ahead. I don't think that is possible without considerable deviation from the part geometry but I'm no expert.

 You are definitely more of an expert than me. And yes, we have an error in the geometry. But it depends very much on the time set. If you draw a straight line to the acceleration curve, the distance is the error. The question now is: do we always need a perfect system? Not in rapid feed and not in jog.
The idea of integrating trajectory planning into an S-curve is as ingenious as it is difficult. And great respect to try solving that. My idea was perhaps to approach the problem in small steps. Maybe then we can see whether the whole thing can be solved differently so that it isn't so complex.

Hi all again,

The cmake project of my linuxcnc fork : github.com/grotius-cnc/linuxcnc/tree/main/cmake is still compiling.

I started the axis gui, scurve config by executing the runtest in directory : github.com/grotius-cnc/linuxcnc/blob/mai...onents/sc_tp/runtest

This is starting a axis gui, performing the scurve motion along the linuxcnc start screen letters.

An sich this works, but code is not finished.  From here i could give it a fresh new try.










 

@Grotius Thanks for the updates - I had a lot of issues getting it to compile the first time around but it appears this resolves a lot of them.

Do you use Discord or IRC? Since you're back I would rather assist you than to attempt re-structuring this on my own. I'm confident I can get a couple other people involved as well if you're interested in this, and with a few people working together perhaps we can solve this more effectively than each of us individually, especially since you're the one with the most familiarity with both the trajectory planner and with implementing the Ruckig lib that I know of.

Grotius, I'm really glad to see you back on the forum. I've been eagerly waiting for your return. I've done a lot of work using Hal. It would be great to join forces. I'd like to add you to my projects on GitHub. If you could share your contact details for access, I'd happily grant you permission. There's indeed a significant amount of work done there.
UPD
I've added you to one of the projects. We'll need to discuss and go over the work that's been done and what needs to be accomplished. And, of course, assist each other