Trajectory Planner using Ruckig Lib

I think we are cross talking here. Linear moves have a fixed constant acceration with infinite jerk. Arcs will have a variable acceleration in each axis, BUT the start and end points will still be infinite jerk.

G64 works by effectively creating variable acceleration to blend moves effectively controlling jerk. Depending how the planner works of course, it will still have some jerk in those blends, but not an amount that typically causes a problem. As in, we don't care (much).

The only points in G^4 mode that are problematic for jerk is the beginning, and end of any segment. G64 "breaks" continuity at various points when it simply cannot blend. Obviously the star and end of the program is one such break because you need to come to a stop.

Having jerk control ONLY on exact stop would raise linuxcnc to the expected performance of a basic industrial control and I think this needs to be done and polished FIRST long before people get off into the weeds of jerk limiting more complex motion.

Here is my machine cutting. Always a good example cause it is high acceleration and speed so it shows you very clearly where the clunks are. The whole program for the most part falls under g64, and is largely smooth. It only create a bad jerk with there is a non smooth condition.

Lots of controls have better HSM motion than linuxcnc. many use splines etc. HOWEVER this does not directly have anything to do with jerk control. This happens a lot in discussions on the matter, people conflate the 2. In software I'm sure there is some intermingling of the functions, but as concepts we need to separate them.

The trajectory planner is I guess level "2" of the operation. Jerk control is level "1" if you will. Jerk control will tell the trajectory planner how it is ALLOWED to accelerate. Before 2.5 we hade a terrible trajectory planner. then we got the new one which put linuxcnc many notches above where it used to be, and above many other hobby controls. What is keeping it behind industrial is NOT that trajectory planner, but jerk control.

Once there is jerk control then it would be great to revisit the planner with deeper look ahead and other clever features to make HSM better.

Lcvette wrote:

Other controls that deal with cam output and smooth out motion don't suffer from these issues.   There are no settings currently that resolve said issues,  G64 helps but does not eliminate and only works in some instances.   A trajectory planner that outputs an adjusted tool path preparing motion into smooth curves and tangent arcs îs what I've found to be how other controllers function. 
 

It is very unsettling when my 8k lb machine tries to walk around the shop floor and I know I'm not the only one with this issue as I have had this conversation with several others experiencing this issue.  I cannot tell for certain but it appears from your video that your machine probably weighs what one of the vises on my table weighs so it's likely not as big of a deal and hardly noticeable with such a low moment of inertia.  There are no settings in the cam softwares I've used that eliminate tiny line segments in adaptive tool paths which are a very large percentage of every part being programed in most scenarios.   These don't only occur at the end of a program but all throughout the adaptive cycle as shown in the case studies I posted previously.   I would think a trajectory planner that smooths out these segments to longer smoother tangent geometry will help this tremendously.   Coupled with s curve acceleration seems it would do wonders for these issues. 

You mention jerk control,  can you expand on exactly what that encompasses and how it actually would work if it's not an improvement of the trajectory planners function?   My limited understanding is that the real-time aspect requiring linuxcnc to be able to come to a complete stop by the end of a segment move, and this is what creates the stuttering.  It occurs while consuming consecutive small line segments and the velocity changes to allow a stop to happen based on the acceleration settings from the axis configuration and the commanded velocity being calculated with the segment length.  What will jerk control do for this and how would it be applied? I don't know enough about it to say if I think it's wrong or right,  but your statement of what areas are important to users I disagree with completely based on my experience over the past 5 years dealing with and desperately trying to find a solution to those phenomenon.   

From what I'm seeing here in the way of progress,  it appears these awesome contributors are on the right path.   Couple that with what tormach claims as an updated trajectory planner that is allowing their new mx1500 to gobble up high speed machining strategies smoothly and it certainly looks to me like all the ducks are marching in line.  

"It is very unsettling when my 8k lb machine tries to walk around the shop floor and I know I'm not the only one with this issue as I have had this conversation with several others experiencing this issue. I cannot tell for certain but it appears from your video that your machine probably weighs what one of the vises on my table weighs so it's likely not as big of a deal and hardly noticeable with such a low moment of inertia."

actually it is worse with mine. the machine weight about 200lbs. it moves several inches around if its not bolted down. but i also had issues with my brother tapping centre which are well documented on this forum - video posted earlier in this thread too. The motors would not tune, largely because linuxcnc's infinite jerk wreaking havoc on the slot responding servo drives.

"Coupled with s curve acceleration seems it would do wonders for these issues.
....
You mention jerk control, can you expand"

S curve acceleration IS jerk control. Jerk is the mode of motion above acceleration. (position, velocity, acceleration, jerk). Technically we are not talking about s curve acceleration her, but rather s curve velocity. acceleration become trapezoidal. jerk becomes a constant. You can keep going up the chain of course and get s curve jerk, but s curve velocity is "good enough" here.

All I am trying to say here is to not mix jerk control and constant velocity functions and ideas in this thread. They are separate things and need to be tackled separately. Once you start mixing in trajectory planning concepts it confuses the topic a lot. jerk control FIRST, then the rest. Otherwise you are trying to build the house before the bricks have been made.

Jerk control on exact stops will fix 80% of your issue for what its worth. Through the program run, constant velocity is "breaking" every so often (every few second or even many times a second depending on the program). When it breaks at a transition that cannot be blended, you get an exact stop, even if you have not technically exited g64. Jerk control needs to be applied to those moves ideally. While g64 is actually being continuous, jerk is already limited to a good degree.

Hope that makes some sense.

Hi Guy's.

Nice discussion.

I finally found the G64 P & Q values for the trajectory planner.

The plan coming time is to integrate clodhoids into the linuxcnc interpreter.
The gcode name for clothoids is defined as G9.

So user can simply load his gcode file. We check if the file contains G64 params.
We then do G64 P&Q value optimalisation for entire gcode file, this is done offline.
Then we save the optimized gcode as a copy and load the copy into lcnc nml again.

The gcode is now reading the G9, the block is enchanged, checked, and now working on execute_block.
I will make notes on how to add stuff to the interpreter.

Earlyer today the repository is initialized from linuxcnc zero. You can now follow the commits i have done.








 

That's awesome Grotius

Looking forward to trying this out