linuxcnc trajectory planner

How important is rigid tapping for the planner?

Certainly an important function (at least on some machines) but likely does not need optimization. Problem might be that the end position is not known before it is actually executed (I think).

[edit]
It might be a good idea to exclude the difficult cases for now. There are likely others, like where the gcode execution depends on input during runtime (eg where probing is run during gcode execution).

While probing its also important to have predictable decceleration distances. Otherwise it is not easy to implement safety functions.

Im not sure where to place my thoughts. So maybe its wrong in this thread.

Best regards
Julian

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

Edit:

We are now at the stage that the trajectory is filletized with 3d bspline's.
For the 3d bspline's i used a lib called tinyspline ,    instead of linking to the huge opencascade lib.

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

This is usually the point where I get rid of G2/3 in all my postprocessors of my CAMs... Didnt you had the discussion wheter to use G2/3 or not? I think in the end this whole topic is one reason why a lot of systems use only G1 in small lenght of course. I assume it would make a lot of things easier, or am I wrong?

Best regards
Julian

@Hi Julian,

As i speak for the programming world, i suggest programmers love to describe a line, arc or spline using a few points.
As memory efficient as can be.
But i get your point.

The error i was getting, i think i figur it out.

The arc function that get's the current point on the arc does this not
by giving it a 0-1 progress.
Instead a 0-arclenght input is the way to do it.
So here i was wrong. But it's also poor commented, so i could not know it so easy.