LinuxCNC S-Curve Accelerations

Jerk limit to the point of seeing your machine move sluggishly? Béziers are Just to be able to get better cornering speeds, because tangent arcs are not optimal for covering with jerk limit.
Scope of planner type 1 is jerk limit to a crawl if necessary? Like the 0.0001 G2 curves that ruediger123 shared. Done with small G64P tolerance, I agree those should just slow down as much as you need to follow path within tolerance, BUT for a square with NO programmed corners, blend with arcs and parabolas are acceptable? Just slow down as much as we need to follow the blend arc? Point cloud line to line is another issue, slow down to keep everything smooth? but then you will see the machine smoothly follow your point cloud, but it will speed up and slow down, speed up and slow down, because we are not trying to maintain velocity, we are sacrificing it, and because we work mostly segment by segment, I don't see an easy way out, Béziers could give us a better path, but we will need to figure out where and how to stitch them smoothly. and how to do it while the machine is in execution, we can't plan the whole thing offline.

What I mean it it becomes development hell and the project dies, and it is the least critical part of the system we need.

Sure, it is absolutely what we want in the end, but getting there is just not happening.

Option 1 is likely a completable project and "good enough for now".

grandixximo wrote:

You cannot maintain velocity, follow the exact programmed path, AND have smooth jerk.

This is physically impossible. What I am saying is I would sacrifice velocity rather than programmed path on G2/G3 programmed arcs. At the moment if you run something with tangent arcs even with G61 the velocity is kept, this messes with jerk. G61 with jerk will have to slow down more.
For many line segments G64 Pxx it also slow down more, the more tight the tolerance, the smaller blending arcs the slower you have to move.
Béziers will give you better speed, because you can run them faster, but they are NOT arcs, meaning when you program a square for example, just 4 lines, you set G64 to 0.5 let's say, what kind of path error would you accept? A 0.5mm perfect radius which I have to slow down more to make smooth, or a squashed up Béziers which I can run faster?

Considering option 2, your set your priorities.

So for example the P value says you need to stay within 0.001mm, then that is your upper restriction for corner rounding, no matter what method you use. your lower restriction is then velocity.

So if I'm taking a corner at 20m/m and my p value and acceleration/jerk values mean I need to slow down, I need to slow down. HOWEVER, if I am taking the same corner with the same p value but only moving 1m/m then the p value is reduced until we hit 1m/m. You do NOT automatically round all corners up to the P value (something i think grotius' version did).

But like I said, I would focus on option 1, and when that work, fully, completely, bug free, we can look towards a new ground up TP with multiple jerk limited constant velocity strategies and more advanced look ahead (which is kinda what tormach did for the 1500).

The brother speedio C00 is a good example to look at. They have SEVERAL constant velocity modes you can choose in g code depending on the operation. some hold tighter paths for finishing, others hold higher speeds for roughing.

Another one to look at is fanuc and siemens, who use spline fitting.

But like is said, this should not be the focus right now. This is phase 2.


 

rodw wrote:

I thought jerk limiting was purely about acceleration. To extend it to varying the path seems to me is really scope creep. Get it working without changing the path and include path optimisations at a future time and write better gcode for now.

jerk limiting may permit higher maximum acceleration. Currently MAX_ACELERATION is set from a combination of motor dynamics and physics by the machine builder Eg the inertia in a heavy moving table may require a lower acceleration than what the motors are capable of so they are not overcome by inertia on deceleration and cause following errors. Its probably valid on a jerk limited machine to increase acceleration. In this context, some violations may be valid.

Absolutely correct. 
It is a constant fight to keep people from mixing jerk - 3rd order motion - with G64 constant velocity algorithms. These are 2 entirely independent topics and should be kept as such.

One thing I also keep seeing is the idea you just "augment" the existing trajectory for jerk limiting - rounding corners and such. This is not gonna be the route to success. Jerk (snap, crackle, pop - yes those are the real terms) needs to be in the core motion planning with velocity and acceleration.

The jerk limits are being respected on the tangent trajectory, the jerk limit works on segments due to the tp architecture, you see jerk spikes because when you look at the joints indipendently, the jerk they experience is completely different from planned jerk, there is cartesian rotation jerk, there are kinematics transitions, the spikes being reported are due to the fact that how the jerk is implemented and the architecture of the tp, we are limited to what we can do. When users report spike and we try to fix them, we find that the problem is not our jerk limiting, it's everything around it that is not made with jerk limit in mind...
The reasoning behind "augmenting" the path, is that we don't like to see the machine ondulate, on something like a multi axis cloud point, we can do it very smoothly but not at constant velocity, look at the actual machine and you'd want to fix it too. Do you want to see nice curves in the scope. Or you want to see the machine behave like it's following a smooth path?  Swift motion requires a swift path, they go together.

grandixximo wrote:

 we are limited to what we can do. 

This statement does no compute.



 

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.

It seems, this routine got no attention. You can do from 3 corner up to a lot, with rounded corners, configurable in the routine as desired.

forum.linuxcnc.org/42-deutsch/58236-g-code-schleifen#341677

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.