LinuxCNC S-Curve Accelerations

Aciera wrote:

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576
 

defenetly is great to have something faster then 1ms .. ethercat can run at 50us with 16axis but this complex calculations are far slower for now 

I think 250us is very pretty goal (common industrial standard) at any hardware and then reduce it based at used hardware 

endian wrote:

Aciera wrote:

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576
 
defenetly is great to have something faster then 1ms .. ethercat can run at 50us with 16axis but this complex calculations are far slower for now 

I think 250us is very pretty goal (common industrial standard) at any hardware and then reduce it based at used hardware 

Note than many ethercat drives are also limited to 1khz in position mode. lichuan is, stepperonline/jss i think is and Im pretty sure the delta b3 is. My omrons I think are restricted to 2khz in csp mode.

For 4khz or 8khz usually you are restricted to other modes. At least in the drives I have. There definitely are (much) faster ones, but they are more specialised gear vs generic milling cnc applications.

Point being, 250us sounds great, but I don't know it needs to be any sort of priority cause only few people could use it. But then maybe those few people are important (like the people I know wanting to nanometer scale optical things and MUST have the higher "loop" speed so can't entertain linuxcnc right now)

Aciera wrote:

I'll try to have a look at the '9D' branch later. Thanks.

which I got not much feedback..


Just as a word of caution from my own experience:
You mustn't expect to much from a forum thread like this. Few people will even read a post that long, fewer still look at the code and hardly anybody will even try to understand it. I know of at least one long time contributor, since retired, who got quite bitter about trying to get sustained and involved feedback here. Even from the very people asking for the specific feature.

I will do it because I want to, don't need cheering up much, although it is nice, it is more about doing something that I can share with everyone, and we are all roughly on the same page, as to what has to be done, but I will do it regardless, and then it can stay in a fork, or merged, we will see...

New PR github.com/LinuxCNC/linuxcnc/pull/3744
Should be able to get new build artifacts, not sure, or you can build my fork
Need some help with testing, thanks!

Hi grandixximo,
Nicely laid out plan.
There is one more nuance for a motion planner that should be considered when looking at a complete re-write for linuxcnc motion planner internals.
For operating robots, some moves are given in joint space and some are given in cartesian space.
For most commercial robots, MOVJ and MOVL/MOVC are separate commands for joint space v/s cartesian space commands.
The MOV* commands also have a sync parameter which chooses if all the axes should start and finish at the same time (rapid move) OR should the motion start and finish at the same time.

When switching between MOVJ and MOVL there is no need to specify the a Kinematics switch. I am guessing they use 2 separate planners and the switch is made at stand still i.e., zero vel and accel for all joints and axes.

Having this ability for multiple on-the-fly switchable planners will make Linuxcnc much more useful for operating robots.

The only reason to bring this up in the conversation regarding jerk limiting is the planner re-write could consider these types of use cases from ground up.
-automata

On what we run on the actual machines we have G12.1 it was an old patch, never fully made it into master, but is much better than what we have now in master, G12.1 Pxx you can have hundreds of worlds switch on the fly, should I made the port? I don't think MOVJ MOVL is realistic, but G12.1 Pxx totally feasible, I already use it extensively.

it is still a switch but nothing moves and can be done on the fly, does that work? or you are looking for something else?