scurve trajectory planner

Hi,

I wonder if you accidentally changed it somehow globally.
I am quite sure i didn't changed code to the interpreter itself. What i use is a recent lcnc clone.
Then the current G64 Q[x] interpreter behaviour is not ok. It's also showing the same at mr. Hmnijp pictures at page 3.
Maybe a dev can take a look if they have time.

Yes better not blend G0's.










 

HI at all.

I have test installation on Debian 10 :

git clone --recurse-submodules codeberg.org/skynet/linuxcnc_scurve_compact lcnc
cd lcnc/cmake
./installer

It not istalled with success, some error in terminal :

Compiling libnml/posemath/posemath.cc
c++: error: unrecognized command line option ‘-std=gnu++20’; did you mean ‘-std=gnu++2a’?
c++: error: unrecognized command line option ‘-std=gnu++20’; did you mean ‘-std=gnu++2a’?
make: *** [Makefile:287: objects/libnml/inifile/inifile.o] Error 1
make: *** Attesa per i processi non terminati....
make: *** [Makefile:287: objects/libnml/inifile/inivar.o] Error 1
c++: error: unrecognized command line option ‘-std=gnu++20’; did you mean ‘-std=gnu++2a’?

and:

/usr/include/ceres/jet.h:165:10: fatal error: Eigen/Core: File o directory non esistente
#include "Eigen/Core"
^~~~~~~~~~~~





eccc..

Hi . i have delete std=gnu++2a'.

but have again anothers error.

too bad it would have been nice to be able to use scurve on debian 10 installations

 

Hi i have install Debian 12 uspace , with linuxcnc 2.9.4 , image the linuxcnc.org.

I have executed :
git clone --recurse-submodules codeberg.org/skynet/linuxcnc_scurve_compact lcnc
cd lcnc/cmake
./installer

have error in terminal:
/usr/include/ceres/internal/fixed_array.h:33:10: fatal error: Eigen/Core: No such file or directory
33 | #include <Eigen/Core> // For Eigen::aligned_allocator

and


/usr/include/ceres/internal/fixed_array.h:33:10: fatal error: Eigen/Core: No such file or directory
33 | #include <Eigen/Core> // For Eigen::aligned_allocator
| ^~~~~~~~~~~~


If add in tray the file ini :
TPMOD = tpmod_scurve

and start sim/axis_9axis_mm.ini have error :

LINUXCNC - 2.10.0~pre0
Machine configuration directory is '/home/fast/lcnc/configs/sim/axis'
Machine configuration file is 'axis_9axis_mm.ini'
Starting LinuxCNC...
linuxcncsvr (23070) emcsvr: machine 'LinuxCNC-sim-9axis'  version '1.1'
linuxcnc TPMOD=tpmod_scurve HOMEMOD=homemod EMCMOT=motmod unlock_joints_mask=0x10
Note: Using POSIX realtime
tpmod_scurve: dlopen: /home/fast/lcnc/rtlib/tpmod_scurve.so: cannot open shared object file: No such file or directory
<commandline>:0: waitpid failed /home/fast/lcnc/bin/rtapi_app tpmod_scurve
<commandline>:0: /home/fast/lcnc/bin/rtapi_app exited without becoming ready
<commandline>:0: insmod for tpmod_scurve failed, returned -1
Note: Using POSIX realtime
milltask (23085) task: machine 'LinuxCNC-sim-9axis'  version '1.1'
halui (23087) halui: machine 'LinuxCNC-sim-9axis'  version '1.1'
Found file(LIB): /home/fast/lcnc/lib/hallib/basic_sim.tcl
setup_kins: cmd=loadrt trivkins
motmod: dlopen: /home/fast/lcnc/rtlib/motmod.so: undefined symbol: tpRunCycle


core_sim:unhandled emcmot<{motmod unlock_joints_mask=0x10}>
         modname=motmod
         modparm=unlock_joints_mask=0x10
     msg=waitpid failed /home/fast/lcnc/bin/rtapi_app motmod
/home/fast/lcnc/bin/rtapi_app exited without becoming ready
insmod for motmod failed, returned -1

Shutting down and cleaning up LinuxCNC...
USRMOT: ERROR: command 30 timeout
emcMotionInit: emcTrajInit failed
Note: Using POSIX realtime



 

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.

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.