Trajectory Planner using Ruckig Lib

"Isn't using s-curves for jogging kind of pointless? You're not cutting anything while jogging, and if you are, you're cutting straight lines, so there is no benefit, just added complications."

No... that is the ENTIRE point. Straight lines are where jerk is a problem.

Do not confuse or conflate constant velocity motion with jerk control. Constant velocity in some ways already HAS it's own form of jerk control and while not perfect, is not a pressing "problem" in linuxcnc.

Jerk control for "exact stop" start and end moves are what is critically needed here. 99.99% of the problem with jerk is in exact stop moves like rapids, lines, arcs, and yes, jogging.

Attempting to encompass moves under G64 early will be the death of this project like it has been every other attempt. It is a vastly more complex task and should be left as stage 3. Stage 1 should be reliable jerk control on moves in exact stop. Stage 2 would be the parts of g64 that "fail" smoothing (sharp transitions). Stage 3 would be g64 motion and anything else complicated.

I would tend to agree, tangential acceleration is usually more of
an issue since it's entirely machine dependent and not like centripetal
acceleration that you can partially  control with G code.
 

For constant velocity machining, the centripetal
acceleration is basically controlled by the gcode
(that is, the shape of the curve), but the tangential
acceleration (acceleration in the line of motion)
is currently just set by an ini constant

PCW wrote:

 but the tangential acceleration (acceleration in the line of motion)
is currently just set by an ini constant

That may not be correct. It certainly isn't for velocity. The ini file sets the velocity and acceleration for each joint. If a linear move is diagonal (where both X & Y axes contribute to the move),  The overall velocity (and probably the accelleration) is higher becasue  both axes are contributing to the move. I would expect the same applies to arcs where the motion at any point in time is tangential to the arc so resolving into X & Y forces will result in contribution by both X & Y axes which I would expect would  achieve the same result as a linear move.

@PCW
the biggest issue I've dealt with is how the machine behaves while following gcode primarily adaptive roughing tool paths and repositioning moves.  most cam software outputs short line segments rather than tangent arcs with longer line segments and without a trajectory planner designed to deal with high speed machining and the short line segments you get fast moves that will shake the machine to death in linuxcnc trying to handle them.  Most adaptive feedrates are much faster than finishing where I use exact stop G61.

I have not experienced much issue at all with exact stop g61 moves especially using roll around corners when making finishing passes, most of the time these moves are tangent arcs,  and straight lines with longer lengths and are made at lower feedrates. 

This of course is just where I find the issues to be and may not be the same scenario for others.  

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. 

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.