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)
You are right, I agree with you 100%, main goal is get lcnc with curves at 1khz ... Timig is very wide and difficult topic but faster code means more play to some latency or timig issues of something, stability, rigidity etc...
I think it is reachable timing .. faster tick means better final result of movement and better regulation feedback with velocity or current control..
Then we can say isolated cpu to sleep if it will runs at longer timing then 250us .. finally we can use more masters at other network interface to run it with different timing if it is needed and then let cpu to sleep
I think Luca's goal are very very well definied .. from my point of view there is missing just pos(t+1) or pos(t-1) for position commands to any drivers which is not using the velocity setpoint(its cosmetic to not see the ferror during movement with position setpoint)
We can runs 16khz with beckhoff but there is latency restictions... for now... I am running 0.5khz with profibus equidistant and it works well but with trapeziodal its was pain.. now with scurve its smooth like butter... lower timing than 1khz are for gentelmen which they know what they are doing.. its advanced I think
