linuxcnc trajectory planner

@Arciera,

For me it's not entirely clear how the probing flow is done, didn't look at is so far.
We will not invest time in it for now, exclude it for now.

@Julian,
While probing its also important to have predictable decceleration distances.
I don't get it.
Im not sure where to place my thoughts. So maybe its wrong in this thread.
Your thoughts are welcome. image missing /media/kunena/emoticons/wink.png

Edit:

We are now at the stage that the trajectory is filletized with 3d bspline's. image missing /media/kunena/emoticons/ermm.png
For the 3d bspline's i used a lib called tinyspline , image missing /media/kunena/emoticons/w00t.png  instead of linking to the huge opencascade lib. image missing /media/kunena/emoticons/blink.png

Ok next step should ideally be visualizing the trajectory including the fillet result. But how?
We didn't coded the plannet yet. And the original planner can not run the fillets.

1. For this i could create a tiny tpmod_viewer.so component  (helper component) wich draws the yellow toolpath line over the gcode path.
2. Modify the original planner, to also run spline fillets. This includes logic to reload the lcnc gcode queue at runtime. More difficult.
3. Create a text file output with trajectory points every mm to load into a external online viewer.

What should we do? Any thoughts about validating the filletized trajectory path?



 

 

Hi.
Probes have a specific way to go, before they break. I use this distance to calculate a max velocity while probe operations. For this I use usually fixed accelaration values. Of course debounce times and so on also.

If there will be non predictable acceleration values, or better non predictable distances right now I would struggle to implement such safety checks.

Attached my safety check for easyprobe.

What should we do? Any thoughts about validating the filletized trajectory path?

I would just go for the easiest solution for now. Once we see that the optimization actually works we can still think about a better preview solution.

Hi Grotius,
Glad to see you are back at this.
For Probing and Spindle Synchronized motion, the use cases do not admit blending. For both we can have the current default behaviour enabled. That will help move things along.
Spindle sync can be done with arc blending as is being done today. The first sync move generally starts from zero velocity and also ends at zero velocity.
For Probing, the start velocity can be assumed to be zero and the end velocity is always zero. (With zero velocity at any end of a segment, we don't need to blend that end.)
For the visualization of the filletized trajectory path, we can start with whatever is straight forward and easy. A separate visualizer which takes input from the terminal output of the trajectory optimization module will also work.

Let me know if you want to test with the Ethercat servo and stepper motor/drives and we can figure out how to ship them out to you.
Eagerly looking forward to the successful integration of this work and trying it out on my mill.
-automata

Hi Guys,

Thanks for your responce's.

@Automata, when time is ready, will check you back for the servo's. I think that's nice to have around here.


We have some results today.
When the buffer is loaded and path is optimized, it writes a gcode file named "validation.ngc" into the ~/cmake dir.
Then you can load this file into lcnc and check results.

Some times the path optimalisation fails. So have to look what's going on.

I have to dive deeper into the original lcnc circle math. As this gives sometimes error's at lcnc runtime.
The message is like "arc radius differs ..." Most of time around 1.4%.
It's now late. Will check some things tommorow.

Attached some test pictures. I used also chamfer fillets for test. And bsplines.

Hi,

G64 P0. Showing the original.
 
G64 P25 Showing the bspline blend.
 

G64 P5 Original this is a square.
 
G64 P25
   
G64 P50


So far it looks the bpsline fillets for attached line's are working fine.
However, for circles, we got this error :
 

I used the lcnc math to interpolate the circle at a given progress 0-1.
Now the result is used as arc point in the gcode, this should be ok.
So i have to look what is going on.

So far so good. We got already some results that looks like a bspline fillet.

updated repositiry