linuxcnc trajectory planner

Yay!
Take you time...











... Is it done yet?

Hi,

Hurray!! \o/  great news to see this in motion once more! so excited!
image missing /media/kunena/emoticons/smile.png
Take you time...
... Is it done yet?
image missing /media/kunena/emoticons/whistling.png

Did some coding today.

Now at the point, the gcode file loads into a vector.
Then it calls the optimizer to optimize the path respecting the gcode G64 P.. & Q.. values.

For the Q value, this is interpreted for removing tiny segments.
For the P value, this is interpreted for path deviation.

For creating the fillets, i will use 3d splines. As the clothoid lib is currently only 2d.

This code is running in the motmod.so, motion control component.
This is not involving the tpmod.so trajectory planners code so far,
the original trajectory planner is still running and functional now.

repository link
vector
optimizer

Hi,

Now given the G64 P.. Q.. value's for a gcode line, this is hiding : emcmotInternal->coord_tp.execTag.fields_float[3 & 4];
This can differ along the file. As the file may have multiple of these commands using different values.

1. The motmod.so (motion controller) component loads the file into a vector.
2. It initializes the lines & arc's inside the vector, just as the tpmod.so does written by Rob Ellenberg. Same struct's are used.
3. It trim's the segments given the G64 P.. value for that gcode line. The trim logic is there to produce a nice trim if it can.
4. Interpolation for arc's is used from original lcnc functions. and tested ok.
5. Interpolation for line's i added a new function wich make more sence.

The picture is a print result after loading the entire gcode, simulating a 5 second delay,
and after trimming is done to connect the spline fillets later on.
 

Next step is to add the spline fillets. But not too fast now.
First create the G64 Q.. (naive cam)  filter function. We want to filter out tiny segments first.

How important is rigid tapping for the planner?

At this stage scurve algorithm is already working?

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