scurve trajectory planner

Hi everyone.
I wanted to ask if a stop function for reading gcode blocks has been provided, via an ISO command.
Several CNCs have a stop for reading prediction.
Siemens uses a command called stopre
Rexroth uses a command called wait
etc..
This is important when performing mathematical calculations in the part program and associating values ​​to variables.
In these cases, the prediction must be stopped, the next gcode must be executed line by line, in order to perform the calculations correctly, and then resume the prediction.
If the prediction is not stopped, the calculations could be wrong, because they are performed before updating other previous calculations.

sounds like a synch or queuebuster command to stop the interpreter read ahead. As an example M66 will do this

There is a sim config that uses a python remap to create a custom Gcode:
github.com/LinuxCNC/linuxcnc/tree/master...remap/stop-lookahead

Hi all,

* Note, the topic name was changed up to 2 times by someone, haha.

Today i added look ahead. This took almost half a day. It's a tiny file, but took a lot off time.
Here is the look_ahead_source_code_file

Now i did a test run tonight using a line fillet algo :  file_path_standard_subseg_line_fillet
This is a simple optimizer algo, that is handy for simple runtests.

The test is done on the extreme  spiral_on_surface file. With tiny segments 0.001mm and deviation P0.0001 Q0.0

Some hal values:

• incements_a_cycle = 2   (planner skips extra gcode segment to keep up with scurve new position)
• ring buffer size = 10
• total loaded segments from program start = 15117
• future buffer, items that are ready to perform, including fillet segments = 3
• cycle dist, is the distance in mm for current servo cycle = 0.0078 mm
• hal traject buffer dist, total todo segments length. ( sum off future buffer ) = 0.1544764 mm

This file run's quite nice for what it is.

 

Git sources are updated.
The first donation is recieved. Thanks ! See the github readme file for more info !

Hi all,

Today i did a test using the clothoid algo.

It turns out, when doing a fast clothoid fit, (using deviation as trim dist) this takes around 0.5ms.
Everything is going well.

When using the excact clothoid fit method, it takes time up to ~200ms when it has difficulties to find a fit.
I will find a solution for this later on.

Most off time the clohtoid fits are ok. I have seen cases where the clothoid fit result looks like overfitting.
This could be investegated later on.

Here some 3d clothoid fit examples. Using look ahead = using endvel.
So far i am happy with the results.

 
 
 

Github is updated.

I have seen cases where the clothoid fit result looks like overfitting.

What exactly do you mean by 'overfitting'?

i assume he means the overshooting on the lower right in the last image.