Advanced Search

This is the most important jerk control needed in linuxcnc. Option 2 is making it work fully with g64 and is FAR FAR less important.

I think that this might actually be the point were many would beg to disagree.

grandixximo wrote:

@ihavenofish I think there's some confusion here worth clearing up, you're right that filtering (like Tormach does) gives you unpredictable deviation, the path ends up wherever the filters spits out, that's not what we're after.

But I think you're mixing up two different things, how the machine speeds up and slows down is jerk control, whether we cut corners is G61 vs G64, these are separate knobs, if you want perfect path following, use G61, the machine will stop at every corner, follow the exact line, no deviation, with proper S-curve planning it'll do that smoothly instead of jerking around, you get accuracy, you give up speed, fair trade.

G64 P is for when you say "I'm okay with cutting corners by up to this much, just keep moving." That's already how LinuxCNC works today, S-curve doesn't change that, it just makes the motion smoother while respecting whatever tolerance you set.

Why Beziers instead of arcs for blending?
Arcs are a 2D thing. Works fine for XYZ, but what's an "arc" when you've got 9 axes moving at once? It doesn't really make sense.
Beziers are just smooth curves that work in any number of dimensions.Also arcs have constant curvature, so when you enter and exit a blend there's a sudden curvature change, the TP deals with this by speeding up and slowing down, which is why you see velocity bobbing up and down through corners, Beziers can match curvature at the transitions, so you get steadier speed through the blend, And on top of that, arcs need sin/cos every servo cycle while Beziers are just a handful of multiplies and adds, In a tight loop running 1kHz+, that matters. Same tolerance as before, just a better curve to fill it with.

This isn't like the clothoid thing, we're not trying to get fancy with exotic geometry, just trying to get smooth motion that respects whatever path constraints you set, does that make more sense?

Just to be clear, the only reason I'm talking about deviation is because S-curve has to work in all modes, including G64 P where the user has asked for corner blending, s-curve isn't only for G61 exact stop, and there will always be a fallback to trapezoidal via HAL pins, some operations like threading, tapping, and probing need the tighter timing that trapezoidal gives you. You can hook planner_type to an M-code and switch modes in your G-code when needed.

I am not mixing up anything. This is literally what I've been saying the whole time. You literally just repeated what I said several posts ago.

S curve DOES NOT HAVE TO WORK IN ALL MODES. This is the point of my "option1" for exact stop as I described earlier (and lead ins and outs of g64 moves). This is the most important jerk control needed in linuxcnc. Option 2 is making it work fully with g64 and is FAR FAR less important. Option 1 is critical, option 2 is... optional. This is why every single jerk control project fails. People jump at option 2 and give up.








 

Hallo Mario,

Laut mein Verständnis musst Du noch eine Konfiguration hochladen. Den Thread durchlesen ist sicher eine gute Idee, aber die ersten Beiträge sind 3-4 Jahre alt und nicht mehr unbedingt relevant.

Gruss,
Luca

@ihavenofish I think there's some confusion here worth clearing up, you're right that filtering (like Tormach does) gives you unpredictable deviation, the path ends up wherever the filters spits out, that's not what we're after.

But I think you're mixing up two different things, how the machine speeds up and slows down is jerk control, whether we cut corners is G61 vs G64, these are separate knobs, if you want perfect path following, use G61, the machine will stop at every corner, follow the exact line, no deviation, with proper S-curve planning it'll do that smoothly instead of jerking around, you get accuracy, you give up speed, fair trade.

G64 P is for when you say "I'm okay with cutting corners by up to this much, just keep moving." That's already how LinuxCNC works today, S-curve doesn't change that, it just makes the motion smoother while respecting whatever tolerance you set.

Why Beziers instead of arcs for blending?
Arcs are a 2D thing. Works fine for XYZ, but what's an "arc" when you've got 9 axes moving at once? It doesn't really make sense.
Beziers are just smooth curves that work in any number of dimensions.Also arcs have constant curvature, so when you enter and exit a blend there's a sudden curvature change, the TP deals with this by speeding up and slowing down, which is why you see velocity bobbing up and down through corners, Beziers can match curvature at the transitions, so you get steadier speed through the blend, And on top of that, arcs need sin/cos every servo cycle while Beziers are just a handful of multiplies and adds, In a tight loop running 1kHz+, that matters. Same tolerance as before, just a better curve to fill it with.

This isn't like the clothoid thing, we're not trying to get fancy with exotic geometry, just trying to get smooth motion that respects whatever path constraints you set, does that make more sense?

Just to be clear, the only reason I'm talking about deviation is because S-curve has to work in all modes, including G64 P where the user has asked for corner blending, s-curve isn't only for G61 exact stop, and there will always be a fallback to trapezoidal via HAL pins, some operations like threading, tapping, and probing need the tighter timing that trapezoidal gives you. You can hook planner_type to an M-code and switch modes in your G-code when needed.

Hakan wrote:

There was a question on that drive before in the forum, was that of any help?
Not exactly the problem you have if I recall right, but anyway.
Hoping to avoid looking at all supplied files hehe.
 

Maybe not so Lucky. I did find a thread on a 2 axis drive that had the same issue but it was never resolved.  I think this is  a deeper problem but don't know why. At least I have the config sorted out and working BUT....

Joint 0 is working perfectly now but Joints 1, 2 and 3 do nothing. The statusword etc are not updating so I am beginning to think this is an issue with our drivers etc. Is it because there is not a slave for every drive? Maybe there is something to enable the later drives so will dig.
I've updated some files attached here.


 

There was a question on that drive before in the forum, was that of any help?
Not exactly the problem you have if I recall right, but anyway.
Hoping to avoid looking at all supplied files hehe.

rodw wrote:

Hakan wrote:

You hit the weak point in linuxcnc Ethercat.
Position feedback from a drive is always two servo cycles behind.
Following error due to this is at least axis speed x 2 x servo cycle time.
You can easily verify this.

 
Not sure how this can be. The servo thread fires every 1 Ms (1000 usec), If you do a trace, It might take 200 usec to execute, then it sleeps for the remaining 800 usec) until it fires gain. The Ethercat thread and the Linuxcnc servo thread are synchronized. We read from lcec at the beginning of the servo thread execution, do our stuff, pids and position adustments etc then write write the result back to lcec then sleep as normal for the remaining 800 usec. How does it lag 2000 usec behind?
  

I thought it was 1 frame behind. but it definitely is behind. People trying the lichunan drives were having this issue when trying to use velocity command.

The WHY is above my pay grade.

grandixximo wrote:

If filtering is what you call s-curve, that will not take long to implement, but that is practically the same as setting s-curve on your servos, but you have a nice parameter in the gcode which you can tweak. But  mind that jerk filtering WILL change your path, this is as far as I understand just a lazy afterthought patch fix.

Mine and YangYang's approach: "We will deviate from the commanded path by at most P, using this specific mathematical curve."
Tormach's approach: "We will filter the output and try to keep deviation reasonable, probably, mostly."
For you to object to Beziers on path-purity grounds while advocating for Tormach's method is... inconsistent, to put it politely.

Sigh.

There should be no deviation. ever. period. If the word deviation comes up, we are not talking about jerk control anymore. 

Option 1, then option 2. Option 2 is mostly useless without Option 1. Filtering doesn't work for me as it is not controlled motion. As you say, we can just soften the servo response for that and we all know that is NOT a good plan.

So it does sound like we need a ground up new TP to actually get anywhere with this. A bit disappointed as this means tormach's implementation was kinda misrepresented to me (not by rob, I never talked to him directly).

That's said, I still feel like this would be great to get implemented anyway, as it might make a bit of a stop gap incremental improvement even if its not the end goal. it would not meet any of the requirements for the lemontart bounty though.

Sleepy time.



 

If filtering is what you call s-curve, that will not take long to implement, but that is practically the same as setting s-curve on your servos, but you have a nice parameter in the gcode which you can tweak. But  mind that jerk filtering WILL change your path, this is as far as I understand just a lazy afterthought patch fix.

Mine and YangYang's approach: "We will deviate from the commanded path by at most P, using this specific mathematical curve."
Tormach's approach: "We will filter the output and try to keep deviation reasonable, probably, mostly."
For you to object to Beziers on path-purity grounds while advocating for Tormach's method is... inconsistent, to put it politely.

Hakan wrote:

You hit the weak point in linuxcnc Ethercat.
Position feedback from a drive is always two servo cycles behind.
Following error due to this is at least axis speed x 2 x servo cycle time.
You can easily verify this.

 

Not sure how this can be. The servo thread fires every 1 Ms (1000 usec), If you do a trace, It might take 200 usec to execute, then it sleeps for the remaining 800 usec) until it fires gain. The Ethercat thread and the Linuxcnc servo thread are synchronized. We read from lcec at the beginning of the servo thread execution, do our stuff, pids and position adustments etc then write write the result back to lcec then sleep as normal for the remaining 800 usec. How does it lag 2000 usec behind?
  

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

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.

 

For the CSP and similar modes generally the target position is fed directly from the joint pos-cmd output, so it does not go through a PID control to account for error like you might see in a velocity control loop with positional feedback.

NWE wrote:

I have to order one of these. Will probably take 30-60 days to get to me. About a month to cross the Pacific plus 5-10 days in customs plus 5-10 days ground freight....

Message them here lichuanmotor.en.alibaba.com/productgroup...408298/EtherCAT.html

They shipped DHL and got to me across the Pacific in about 4 days for USD $32

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...