LinuxCNC S-Curve Accelerations

Most of my testing was on 5 axis, need some help with the performance on a cloud of points, but it is not half bad in my testing, I compared with a commercial 6 axis robot on same point cloud, and well maybe we are half the way there, which is not too bad IMO

active setup is faar miles in front of everything... it is very interesting stuff 

please reupdate repo /configs with scurve_example.hal and .ini files config for easy setup for other users as it was 1.1.2026 for testing ...

 

I moved them

sim
axis
axis_mm_scurve

instead of the main folder.

andypugh just sent me the Tormach 9 axis code, I will be looking at that closely...

testing in full stream ... its runs at 2ms cycle with profibus master without significant problems ... hardware beckhoff C6930-0060 with native driver at 3.4ghz 


video - 

Thank you so much for the independent testing, really appreciate it.
On another note, for who is not following the PR posts, Andy Pugh and the other devs decided to merge as soon as they can into master branch, so that it can get more wide testing, and probably be part of the 2.10 release, also I will leave here the same thing I posted in the PR on GitHub:

By the way there is also a PLANNER_TYPE = 2 which I have not documented at all, I intended to remove it, but have not come around to do the cleaning yet, that could be cleaned, or the community could be doing some further testing.

The main practical difference is in how they handle cornering velocities during blends, type 1 is more cautious, while type 2 balances smoothness with speed, in my testing type 1 wins out in most scenarios.

A couple of us played briefly today on Trixie and we built some debs to share with a few friends.
In the sim, I would like to see 
HOME_SEQUENCE=1 for all joints 
This will enable the home all button to save some time when playing. No need to home each joint.

I'm just having trouble with a corrupt APT system on my Linuxcnc PC and I am getting latency errors on my  office PC so I could not see much but I did briefly see some nice curved graphs in halscope.

I think if it was committed, there would be a stream of testers to find any remaining bugs...
 

I saw it the first time I opened it. Couldn't bother myself to fix the sequence on a Sunday afternoon lol
I will fix it for y'all tonight.

Edit:
Done, pushed to github, the ini configuration is better suited for quick testing, you don't even need to home it ([TASK] NO_FORCE_HOMING = 1), but if you do is just one click, and you got infinite limits to load your wildest g-codes.

is homing at joint.0.index_enable avaible?

I can not home my profibus sstuff it looks like index_enable is still down .. 

I have had to uuse the NO_FORCE_HOMING = 1

thanks

HOME with index should be available, nothing about homing should have changed other than the homing movements being now jerk controlled, but I'll double check on my end, you still have to enable

HOME_USE_INDEX = YES

In the ini file for each joint you want to home using index

Edit:

Yeah, triple checked, homing index should work as expected, just has to be set proper, mind that machine movements will be effected by the s-curve even while homing, if you do not want that, you can link all joint.N.homing pins with or2, then to a mux2, and then to the ini.traj_planner_type pin in hal, so when you home you can have planner 0, otherwise planner 1, I originally had an INI flag to disable s-curve while homing, if you guys think is necessary I'll add it back, but I ended up not liking the machine shaking up only when homing, I want it always to be smooth now, I'd rather readjust the homing vel to compensate for the longer but smoother movements.

yes exactly ... if all axis homed then ini.traj_planner_type == 1 else 0 ... its important for external drivers over buses maily... 

2nd day of testing at hardware is away... motion is way smoother and followinf error ar beginning at ending of movement is away too 

thanks