LinuxCNC S-Curve Accelerations

rodw wrote:

BUT for a square with NO programmed corners, blend with arcs and parabolas are acceptable? 
This is hypothetical and the gcode is really bad, an error waiting to happen. You might as well attempt to cut a 7 pointed star and break things properly!
Time to get out of the office and onto a real machine!
You should be either looping the corners or adding fillets to the part. If you choose to write bad gcode, be prepared to suffer the consequences. Fixing that is your problem, not the S code developers.

This is the mix up between cv and jerk. This square either has to exact stop at each corner, where linuxcnc has no jerk limiting and makes a big bang, OR, you are running g64 and it rounds the corner base of feed and p value and already functionally works in linuxcnc (it can be better absolutely, but it is that part that DOES work good enough). So clearly we want jerk limiting on the first case (option 1) and its a bit less important in the second case (option 2)... BUT in no way should jerk limiting be directly influencing the path. At all. Ever.

There should be no talk of altering the path, or corners when discussing jerk limiting. In the same way you don't talk about path deviation when discussing acceleration, or velocity. The TP has to hit the path precisely in exact stop mode.

And 100%, you need to be using this on a real machine while you work, not vibe coding and saying "look I made a thing, try it on your expensive equipment for me!". Not even disparaging vibe coding here either if it gets the job done, but you need to actually understand what you are trying to achieve first, and I'm not 100% sure everyone is on the same page.

As I've dug into linuxcnc from a "not particularly good coder" stand point just learning the functional structure, I reaaaaally don't think this is going to happen without a ground up new TP. Option 1 or 2. What seems to be the case is linuxcnc TP is "built different" from most industrial ones and the order of processes causes some problems for simple higher order motion integration.

Can people involved with the existing TP can maybe offer some more complete explanations here? Do we need a structurally new TP to get what we want (option 1 first, 2 second)? I always get some glossed over answers when I search that never supply a definitive "not this isn't going to work at all because:" And we also have the bizarre paradox that linuxcnc in fact surfaces better than many low to mid end jerk limited controls, so we don't want to be losing that either.

And as always, not discouraging anyone or any idea, I have just seen this start and fail SO many time, when literally every other control has had it since the 80s and it always feels like the exact same failure mode: distraction away from the root task.

For example YangYang is now looking at stopping to destination with vel0 acc0 jerk0 all at the same time at the ends of an arc segment, in the servo-thread we compute next position forward in time, they keep adding up, and this leads to numerical errors, which make the jerk overshoot near the final destination, then you have to clamp down the error smoothly to arrive at destination, within current architecture you have to overshoot, you have to readjust, he has tried multiple avenues to fix this, nothing so far has worked.
How commercial TP fix this? they don't plan forward, they plan from destination backwards at each time increment with dedicated hardware, and deal with feed override changes by re-planning to a different time destination.
You can probably understand how different LinuxCNC is from commercial controllers, they practically work in the complete opposite way...
Many of the issues we are faced with, have similar kind of solutions in the commercial space, they just don't do it how LinuxCNC does it.
When I wrote "we are limited to what we can do", I intended it in the scope of implementing jerk limiting within the current TP, with tangential jerk limiting code that is being enabled with planner_type 1, and some blending and look-ahead improvements, to try and stick to jerk limited motion, without introducing any non-realtime code in servo-thread, sure a complete rewrite you can do whatever, but that is not something you do overnight. And we are also limited by physics, you can't have high-speed accuracy smoothness all at the same time, physics just don't allow this. I understand most here would sacrifice speed, but there is a camp that would like to squeeze out a bit more speed if possible sacrificing some accuracy within what's allowed by the gcode.

grandixximo wrote:

For example YangYang is now looking at stopping to destination with vel0 acc0 jerk0 all at the same time at the ends of an arc segment, in the servo-thread we compute next position forward in time, they keep adding up, and this leads to numerical errors, which make the jerk overshoot near the final destination, then you have to clamp down the error smoothly to arrive at destination, within current architecture you have to overshoot, you have to readjust, he has tried multiple avenues to fix this, nothing so far has worked.
How commercial TP fix this? they don't plan forward, they plan from destination backwards at each time increment with dedicated hardware, and deal with feed override changes by re-planning to a different time destination.
You can probably understand how different LinuxCNC is from commercial controllers, they practically work in the complete opposite way...
Many of the issues we are faced with, have similar kind of solutions in the commercial space, they just don't do it how LinuxCNC does it.
When I wrote "we are limited to what we can do", I intended it in the scope of implementing jerk limiting within the current TP, with tangential jerk limiting code that is being enabled with planner_type 1, and some blending and look-ahead improvements, to try and stick to jerk limited motion, without introducing any non-realtime code in servo-thread, sure a complete rewrite you can do whatever, but that is not something you do overnight. And we are also limited by physics, you can't have high-speed accuracy smoothness all at the same time, physics just don't allow this. I understand most here would sacrifice speed, but there is a camp that would like to squeeze out a bit more speed if possible sacrificing some accuracy within what's allowed by the gcode.




 

You'll need to change the TP. I'm not offering a $3000 cnc as a bounty for something you can vibe code overnight

Speaking of, a little bird told me that someone with the skills should request tormachs latest source....

DO IT NOW!

I thought it had already been established that Tormach do not have jerk limiting.
Another possibility would be to run a gcode filter to "normalize" the gcode for performance and jerk limiting. Joco's Monokrom filters out all holes and replaces them with its own optimised code with custom leadins so it can be powerful in the right hands...

rodw wrote:

I thought it had already been established that Tormach do not have jerk limiting.
Another possibility would be to run a gcode filter to "normalize" the gcode for performance and jerk limiting. Joco's Monokrom filters out all holes and replaces them with its own optimised code with custom leadins so it can be powerful in the right hands...

Um, what? Where did you hear this?
Pathpilot for the 1500mx has jerk limiting and other g64 features. However the source people have had access to on here (like grotius) was an older version without these features.

So, ask tormach for the source again, it should now be the 1500mx version.

 

I have v2.12.1 seems from march 2025, I have email from Robert Ellenberg - Software Team Lead at Tormach from 2 weeks ago, we should have a meeting on the 28th.
Quote:
Hi All,

Sorry for the wait this week! I'd love to do a zoom call and dig into the trajectory planner differences. The S-curve planner PR is an exciting change, and it would be awesome to learn more about it. There are a few times during the week that are good for me to do a long meeting:

Fridays between 10AM-4PM EST (Jan 16, 23, and 30)
Wednesday Jan 28th between 11AM-4PM EST
Thursdays in Jan, 9PM-11PM EST


Given the volume of things to discuss, a recurring meeting might be a good idea to spread things out. If we can get a weekly, biweekly, or monthly time on the calendar, it will be easier to get through all of the material, and also deal with new issues as they come up.

In the meantime, here are some quick answers for Greg C's questions:

Does Tormach have any 9 axis .ngc files they use for testing they could share? We have some test cases, but most of them are not real part programs, rather they just exercise the trajectory planner. Some of them may be in the Tormach linuxcnc fork, I'll look through my archives for the rest.
Does Tormach have any build tests set up that they are willing to share? The tormach linuxcnc fork has extended tests that would be great to include upstream, most of which are subdirectories in the "tests/motion". There are test cases for probing, cutter compensation, spindle synchronization, and a few others.
What changed from trivkins to square3kins, and is any of that worth considering for inclusion in our project? square3kins is an extension of "millkins" i.e. forum.linuxcnc.org/49-basic-configuratio...kins-or-millkins-xyz . I can discuss in more detail, but main additions are rigid rotation of the coordinate system (correct for table surface not parallel to the motion axes) and atomic update of parameters
Are there any parts of the implementation that were accepted as “good enough,” deferred for later cleanup, or known compromises that we should be aware of? Yes, depending on how stringent your definition is. Most of these are documented in code with TODO / FIXME tags. This is a detailed subject, but one example is how we handle blend tolerances in 9-axis blending. In lieu of solving the kinematics, we basically assume that "deg = inch" when sizing the blend arc. This is suboptimal but generally safe (1 deg is 1 inch displacement on a ~57" diameter part).
If you were implementing this today in a joint-based architecture, is there anything you would change about the overall approach or design? This is another long subject, but the biggest change would be to make the have the trajectory planner work in joint space, and use the realtime kinematics layer only for minor adjustments like squareness comp. To actually do that is a big effort (biggest change is incorporating kinematics earlier motion planning).


Also, to answer an earlier question, the limited jerk method we're using in the Tormach fork is an extension of the current planner. A quick summary of what we did (happy to discuss in more detail in the call):

Filter each axis independently with a moving average filter, and set the length of that filter via the new M59 command (M59 D# in ms)
Reduce the feed rate of high-curvature moves such that the axis filtering does not "round the corners" more than the specified tolerance (M59 H# in length units)
Apply custom settings in certain conditions to avoid lag (tapping, threading, probing)
Change the notion of "done" in the TP to wait for the nominal path to be done + average filters fully drained


The main benefit is the user has control over smoothness, path accuracy, and achievable feed rate. For example, you can do high-load roughing with more smoothing and looser path tolerances. For finish passes, you apply tighter path tolerances. This limits the achievable feed rates, which is generally tolerable on fine finish passes.

Best,
Rob