LinuxCNC S-Curve Accelerations
23 Mar 2023 23:30 #267383
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi, a little project update.
Today i finished the sc_look_ahead. I renamed it to sc_optimizer.
It's now a sort of path-rules module. Wich can add extra path-rules any time.
For now it has a 5 important path-rules under the hood. This will cover the most annoying things.
The code is quite compact. Tested with 2 motion scenario's so far.
We have to decide how to use it. I guess it could be used in 2 way's :
1. Do a optimizer over the gcode when it loads.
2. Do a live optimizer, for example look ahead 20 lines of gcode.
3. Do bot'h 1 & 2.
4. A better idea?
The sc_optimzer_gui is a simple test suite to perform sc_optimizer tasks.
It has also a tiny calculator to see how gforce relates to speed, arc diameter.
I think easyest way is to make a tiny list where some value's are already printed.
To be continued.
Today i finished the sc_look_ahead. I renamed it to sc_optimizer.
It's now a sort of path-rules module. Wich can add extra path-rules any time.
For now it has a 5 important path-rules under the hood. This will cover the most annoying things.
The code is quite compact. Tested with 2 motion scenario's so far.
Warning: Spoiler!
We have to decide how to use it. I guess it could be used in 2 way's :
1. Do a optimizer over the gcode when it loads.
2. Do a live optimizer, for example look ahead 20 lines of gcode.
3. Do bot'h 1 & 2.
4. A better idea?
The sc_optimzer_gui is a simple test suite to perform sc_optimizer tasks.
It has also a tiny calculator to see how gforce relates to speed, arc diameter.
I think easyest way is to make a tiny list where some value's are already printed.
To be continued.
Please Log in or Create an account to join the conversation.
24 Mar 2023 01:55 #267393
by rodw
x 2
Replied by rodw on topic LinuxCNC S-Curve Accelerations
Grotius = T1000 Terminator
He does not give up, ever.
x 2
No we need you around lurking in the shadows to keep the T1000 Terminator on track...rodw: I didn't intend to sound negative. back to lurk mode for now.
Please Log in or Create an account to join the conversation.
24 Mar 2023 14:26 - 24 Mar 2023 14:28 #267408
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi,
He does not give up, ever.
Have to confess sometimes it's better to give up in sometimes
for your own health and mental state.
Otherwise you can make your own live very hard,
and you can become angry on yourself, because things do not
succeed.
the algo of cavalier contours & auto nesting was going to far for me.
Cavalier contours is like magic. Really hard to design such a algo.
A nesting algo idem dito. Also magic, haha.
I guess we are lucky today.
I tested the planner with the optimizer attached, cq look ahead function. It looks ahead 20 lines.
If user is at program line 50, the optimizer takes 50 as start & 50+20 as end range.
So far so good.
The testcase was done with multiple short lines after each other.
The motion:
Example without sc_optimizer :
Example with sc_optimizer :
Mention:
Half way the motion, the red curve has a dip. This is because there is a corner angle at that point. The last motion has
a y-value of 50.
You can also mention the first 4 motion's are fused together, because they are of type G1.
Without the path optimizer, the machine would stop every motion line.
He does not give up, ever.
Have to confess sometimes it's better to give up in sometimes
for your own health and mental state.
Otherwise you can make your own live very hard,
and you can become angry on yourself, because things do not
succeed.
the algo of cavalier contours & auto nesting was going to far for me.
Cavalier contours is like magic. Really hard to design such a algo.
A nesting algo idem dito. Also magic, haha.
I guess we are lucky today.
I tested the planner with the optimizer attached, cq look ahead function. It looks ahead 20 lines.
If user is at program line 50, the optimizer takes 50 as start & 50+20 as end range.
So far so good.
The testcase was done with multiple short lines after each other.
The motion:
Warning: Spoiler!
Example without sc_optimizer :
Example with sc_optimizer :
Mention:
Half way the motion, the red curve has a dip. This is because there is a corner angle at that point. The last motion has
a y-value of 50.
You can also mention the first 4 motion's are fused together, because they are of type G1.
Without the path optimizer, the machine would stop every motion line.
Please Log in or Create an account to join the conversation.
27 Mar 2023 22:35 #267634
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi Spumco,
From user perspective it's a logic explanation from you.
If you look into the previous linked c file, you can see functions like : tp_addline or tp_addcircle or tp_isdone.
In the original tp.c file there is a queue vector that has a size of about 10 lines of gcode.
I speak in therms of gcode to keep it simple. It's actually line, arc data, some speed and acc data etc.
It comes close to a actual gcode line.
Every time tp_done=1, the queue may be updated with new gcode line. It works like a c++ vector operation.
It can add a line, remove a old line from the bucket. The queue is like a tiny program that feeds the component.
For me it's not clear if i don't use the queue bucket to hold the gcode lines, why it's dumping the whole gcode file at once
if i do a tp_isdone request.
The first request goes ok, second request is dump mode.
And it's not clear to me where the tp_addline, tp_addarc requests actually came from?
With the bird eye view, i can search for the functions, but these 2 appear only once.
The goal is to clean up the original tp.c file to something minimal that is working, even without vel,acc etc.
It just has to do a working cycle. May even be without moving the tp itself.
From there i have a nice and clean starting point to integrate the scurve code.
From user perspective it's a logic explanation from you.
If you look into the previous linked c file, you can see functions like : tp_addline or tp_addcircle or tp_isdone.
In the original tp.c file there is a queue vector that has a size of about 10 lines of gcode.
I speak in therms of gcode to keep it simple. It's actually line, arc data, some speed and acc data etc.
It comes close to a actual gcode line.
Every time tp_done=1, the queue may be updated with new gcode line. It works like a c++ vector operation.
It can add a line, remove a old line from the bucket. The queue is like a tiny program that feeds the component.
For me it's not clear if i don't use the queue bucket to hold the gcode lines, why it's dumping the whole gcode file at once
if i do a tp_isdone request.
The first request goes ok, second request is dump mode.
And it's not clear to me where the tp_addline, tp_addarc requests actually came from?
With the bird eye view, i can search for the functions, but these 2 appear only once.
The goal is to clean up the original tp.c file to something minimal that is working, even without vel,acc etc.
It just has to do a working cycle. May even be without moving the tp itself.
From there i have a nice and clean starting point to integrate the scurve code.
Please Log in or Create an account to join the conversation.
Time to create page: 0.113 seconds