LinuxCNC S-Curve Accelerations

if you don't touch the feed override, the errors can still come up?

grandixximo wrote:

New PR from YangYang is ready, hopefully will be merged soon in master

This adds ruckig in the planner type 1
if you want to test it get the binary from

github.com/LinuxCNC/linuxcnc/actions/runs/21975584400

or build source from my repo

github.com/grandixximo/linuxcnc

Testers are welcome to report here or in github, thanks!
 
Hello gentlemen,

movement are incredible smooth ... basic shaping what I have tested till now is pretty ... but during movement at more points during simulation of rotation interpolation its jumping or woobing ... kind off braking and next accelleration 

most spiking during cloud of points are gone ... some spiking are still present but it a huuuuge step forward 

testing setup 2ms benchtop profibus master 3axis geany gui ... 3 servo axis with synchronized speed control loop at 2ms

some testing fault popups triggered during the movement of file 3_1001.ngc

I am still testing at default simulation file from past but splitted to separated operations ..

thanks a lot for your progress ... I am watching it every single day with mount open and box of popcorn to reading the edits ... 

regards E.
 

I have noticed the slowing during the round movement too but I forgot to noticed it here.... yes it is present and its present during 100% feed value ...

crashes are not present during the 100% feed just if its not 100% ... 

crash log is in the attachement if somebody are interested ... 

I will have YangYang take a look after the holidays, thank you for testing.
We are on a Chinese new year brake for a couple of weeks.
I'm still working on Planner Type 2, will see what YangYang thinks after the holidays, hopefully Rob will also do some testing

hello,

During todays testing Ive noticed time spiking during the G64 P0.005 and less ... I know there is a huge tolerance limit but I am reporting it for full testing approach ... code 1_1001.ngc from .tar file - again simulation or circural interpolation by cloud of point 

otherwise timing get huge improve ... no big spikes and no big spikes of accelleration during the movement too!!!

I wish happy new year to China! Take a rest and we will see us after !

thanks

hey guys

just wondering whats the latest on this.

cheers

andrew

Becksvill wrote:

hey guys

just wondering whats the latest on this.

cheers

andrew

 


Still work in progress

github.com/LinuxCNC/linuxcnc/pull/3807

you can read above, if anyone wants to test what's done so far, they can download the debs from github build artifacts
github.com/LinuxCNC/linuxcnc/actions/runs/22982518117?pr=3807
the above is today's build, scroll to the end of the page for the debs for the different systems, I think I got it to the point where it is in a good enough state for sim testing by the community
To test it set planner type 2, I have included a zip file in this post with my testing settings for planner type 2.
YangYang is refactoring the code, he put planner type 1 on pause because there are certain limitations with TP1 implementation, he cannot reach high speed on short segments.
TP2 will be the general base idea, but much needs to be refactored, the feed override needs to be reworked, kinematics TP and RT servo-thread need to be reworked, there is talk in the github about this, any extra mind is appreciated.
At the moment TP2 generally works, what's still missing from my implementation is spindle sync, I never tested probing or adaptive-feed.
as far as running gcodes and MDI, I believe everything works, but it is far from hardened, it is just me doing testing in a sim, if you put it on your machine, it is at your own risk, play with it in the sim, and let me know how it goes, here, in the gihub PR, or even on my github fork.

Hello, 

I can see merge of your progress to master? Am I right ?

Regards e.

Hi grandixximo,
Congratulations on a viable solution to this long standing gap in Linuxcnc implementation.
I was going through how you have taken into account the kinematics in userspace for planning which is needed for kinematics bounds checking.
I also see that you have made the relevant changes in the kinematics defined in src/emc/kinematics/* files.
There is another set of switchable kinematics defined in the src/hal/components/*.comp files (method made viable by David Muller / aciera on this forum). For example xyzab_tdr_kins.comp, xyzacb_trsrn.comp etc.,
I somehow find the idea of implementing the kinematics as a loadable .comp module compiled by halcompile very fascinating and useful
Is there a guideline on how to transition those kinematics also to this new setup?
-automata

endian wrote:

Hello, 

I can see merge of your progress to master? Am I right ?

Regards e.
 

No, we will make another PR for merging into master, this is more of a testing version, it was shared as a draft, it is good to get feedback on it, as it will be the base for the future work.

automata wrote:

Hi grandixximo,
Congratulations on a viable solution to this long standing gap in Linuxcnc implementation.
I was going through how you have taken into account the kinematics in userspace for planning which is needed for kinematics bounds checking.
I also see that you have made the relevant changes in the kinematics defined in src/emc/kinematics/* files.
There is another set of switchable kinematics defined in the src/hal/components/*.comp files (method made viable by David Muller / aciera on this forum). For example xyzab_tdr_kins.comp, xyzacb_trsrn.comp etc.,
I somehow find the idea of implementing the kinematics as a loadable .comp module compiled by halcompile very fascinating and useful
Is there a guideline on how to transition those kinematics also to this new setup?
-automata

Hi automata,

Good question — the .comp-based kinematics (like xyzab_tdr_kins.comp, xyzacb_trsrn.comp, etc.) were missing planner type 2 support because halcompile doesn't generate the nonrt_attach() entry point or the shared-memory parameter bridge that the userspace planner needs.
I've added a glue header (comp_kins_uspace.h) that makes the conversion straightforward without having to rewrite the .comp as a hand-written .c file. The idea: HAL pin values are mirrored into shared memory by the RT module each servo cycle, and the userspace planner reads a consistent snapshot from there instead of touching HAL pins.
The conversion is 5 mechanical steps:

#include "comp_kins_uspace.h"

Call comp_kins_uspace_setup(comp_id, "mykins", num_joints, "XYZAB") in your setup function after hal_ready()

Replace each *(haldata->pin) with KINS_READ(haldata->pin, N) where N is a unique index per parameter

Bracket kinematicsForward/kinematicsInverse with COMP_KINS_BEGIN(haldata) / COMP_KINS_END()

Add COMP_KINS_NONRT_ATTACH("mykins") at the end of the file

For switchable kins, also sync the switch type with COMP_KINS_SET_SWITCH_TYPE() in kinematicsSwitch().
xyzab_tdr_kins.comp has been converted as a reference example — look for the lines marked with +++ comments. The kinematics docs (docs/src/motion/kinematics.adoc) now have a full section on this with annotated code examples.