Category: General LinuxCNC Questions
Aciera post=316563 userid=25994Maybe this documentation helps:
linuxcnc.org/docs/stable/html/user/user-...gramming-the-planner
From my experience the issue with the jerk is currently unresolvable, you can minimize it to some extent, but ultimately i have found no good solution to how the currently available linuxcnc trajectory planners handle modern code with short line segments and arcs and how the commanded velocity and acceleration settings work. i think the only way to eliminate the jerk caused by high speed moves through short line segments and arc transitions where the motion velocity and acceleration rules come into play is to remove the realtime planner restrictions. because the machine must be able to come to a complete stop by the end of the current or next move, it must change the machines motion to accommodate. this means if the machine needs to be able to stop on a short line segment from a modern cam post output for adaptive clearing for example, and the commanded machine velocity is higher than it could stop when it gets to those short segments, the machine must decelerate to stay within the rule parameters. if the line segments are non uniform in length, the distance to stop requirement changes and the machine acceleration and deceleration is being changed very rapidly through each segment. i find this is where i experience all of the violent jerky motion. using G64 P and Q allows the motion path to make some of the smaller line segments into large line segments, but that just means there are fewer jerk points, not that the jerk is eliminated.
I have pondered this and how it could be resolved, and I **think** it would require the rules be changed in the trajectory planner code. I think a good compromise solution would be a calculation that uses look ahead and the machines acceleration settings and commanded velocity in conjunction with the planner calculating the path and setting the stop point to the next control point in the path that can be successfully stopped at under the currently commanded velocity and the deceleration configuration parameter setting. if that means it requires 1 point or 1000 points to stop, it doesn't matter.
The example here being that to stop within the "1 point" would be where that point falls within the actual stopping distance for the machines parameters when the stop or feed hold command is issued, verse there being a series of very short line segments that may be only a few thousandths of an inch long), what would change with this method is the machine would maintain its commanded velocity through all of the path without having to slowdown for a "potential" call to stop. this will give the machine the ability to move much faster and smoothly through the programmed path without the harsh acceleration and deceleration.
In this regard the machine will always stop within the calculated distance of (current velocity and deceleration rate + subsequent programmed point). in this regard we are freeing up path velocity changes greatly which would result in much smoother motion. the downside is the machine will stop a little slower in the event of a user call mid cycle.
this would only change how quickly the machine stopped on those shorter moves. because when the machine is moving at rapid or at higher feed velocities through longer segments or arcs, the stopping distance and time will always be the deceleration distance from the current velocity.
just my thoughts, and i could be completely wrong, feel free to enlighten me if i am incorrect! I will happily eat crow if it leads to a solution...lol
Chris
