Trajectory Planner using Ruckig Lib

So the underlying problem is the trajectory planner of halcore. This consumes too much time as it
is also added to the servo update thread. It slows down the servo update thread. I think this is the cause
that the production machine on the parport also run's not good.

So i will qreate a chrono timer, to first measure the total time of the trajectory planners cycle.
I expect it will exceed the 1ms time of the servo update cycle, but i don't know for sure at the moment. We will find that out.

I am following this thread ever since it started as I would be interested in the result of this work, but I have not felt I could contribute in way yet. 
Regarding this slow down update of the servo thread, I don't know if you are aware of how OpenCN (forked from linuxnc) works, I know that instead of using realtime kernel, they've done something where a core of the CPU is allocated to ethercat master and only that core is realtime, while the rest of the cores are doing the calculation work. 
I think this video can explain it better: 
Most likely you were aware of this but I said it doesn't hurt asking. 

@Lcevette,

Thank you.

I didn't expect the look ahead, motion speeds over the trajectory would succeed.

Because i didn't really know how to calculate the speeds at gcode segment transitions.

I think we all together made succes.
Without the community input i would certainly not be at this stage.

Once you have something that works on this level, it has value.

@Vmi,

I was not aware of that. It's smart.
I have had an idea to create a virtual ethercat slave that replaces the hal environment.
Just like the ethercat-master examples create their own kernel modules. But it was just
an idea. Better stay at the current hal environment.

I spent a few day's finding the problem of my current situation, where the production machine was not
working as should, both on parport as on ethercat.

The problem is that the stepper motors where rotating very slow and hickey on ethercat.
Where this normally should run with more speed then a parport.

I did a few iso install's including the linuxcnc iso. 4 day's of trying to figur out the problem and no luck.

I even thought yesterday, maybe i have got infected by Stuxnet. Because the ethercat test board has worked without
any problems a few years ago and now it was not working good at all.

In previous post a was able to run a script to run the ethercat steppers on hal-core. So this morning i extended the
succesfull script to finally run the cnc program with it without any problems anymore.

To run the ethercat test board along with the cnc app :


So this start first the "runtest_4_axis_state_machine", this is a script that starts the hal environment with the components.
Then it start the cnc program.

Now this is working as should be.
In the previous i was starting the cnc program as first, then loading the hal environment. Maybe this was causing trouble.
I have readed that user db1981 has also mentioned, first load the important hal stuff.

So in the end, the problem was not a compromised debian iso or a stuxnet or a zero day. It was just loading the
hal & program in wrong order.

Now the ethercat board also failed on a fresh linuxcnc installation yesterday, it moved the motors very slow and hickey,
maybe i have to look what was going wrong there as i now know it runs ok on halcore.

Ok this was a long story. I hope it was not bothering you.


 

I was pretty sure you were aware of this project. I've been talking to these guys last year, they were making tests on a 5axis machine using beckhoff hardware and claiming that it can constantly hold 10khz ethercat master.
There are some things that are not yet supported, like spindle encoders, synchronized motion, etc.
They explain here better on how they generate the positions for the drives using matlab: 


I know you put lots of effort into your solution, but on my short interactions with linuxcnc from a code perspective, it seemed to me a mess from an architecture standpoint. So the fact that they took this to the next level and you don't need a realtime kernel, I think its huge leap forward. Even if this would mean changing all my hardware to ethercat drives.
I can's say I fully understand what you said. I am very interested in this topic, OpenCN seems to have a good foundation from an architectural point of view, but even though I code Java/Kotlin and eventually Python, I don't know c++ at the level I could help with something. (at least not yet)
They are using some protocol buffers to communicate from between the motion control server with the UI app, so the controller app could be on any device/tablet, etc.

My goal is to create a modern cnc UI controller with touch screen and a state machine based UI where you don't see on the screen buttons and widgets that don't make sense at that point in time. (It makes no sense to see jog controls when you're in Auto mode, etc). Everything that Centroid is doing could be done better if we would have a core motion controller that would worth the effort of building on top of it. This is why I never closed this tab with this topic ever since it started and this is why I was so interested in OpenCN.

@Vmihalca,

Thanks for giving your insights.

, it seemed to me a mess from an architecture standpoint
I can agree with that. It's evolved in a spagetti over the years. But it works.
Once you have a cmake project of lcnc loaded "insights into full project files structure relation",
even then it's hard to understand how things are done.

So the fact that they took this to the next level and you don't need a realtime kernel, I think its huge leap forward.
It's very nice you can run ethercat on a non realtime kernel.

so the controller app could be on any device/tablet, etc.
Yes this is nice.

From my standpoint, the goal was to get scurve running inside a custom linuxcnc trajectory planner component.
This evolved in a long forum thread. Many times i thought, it looks impossible to achieve this scurve motion planner.
Everytime there was a problem.  It looked doomed. Like don't value your time with linux. This is some times frustrating.

The last time i was focussing the project only on getting the 3d fillets done over the trajectory.
How to get the optimal velocity profile for a trajectory? How should you do that?

You can say, this forum thread is focussing on the scurve implementation and how to produce a optimal velocity profile for a
multi axis cnc machine, holding tight to valid science paper solutions.

That the trajectory planner now is tested on halcore is just because it has very compact code base, so errors can be filtered out quite easy.
The underlying hal is identical to that of lcnc. So integration when code is complete is more easy.
 

@Vmihalca,

I think you have a nice goal.

If you build that machine gui, and you choose a server type, like lcnc uses nml.

Then you can also connect it to everything.
Halcore can run a server of any type. It's just adding a server and make the connections.
In mach3 they used a numbered list for type of instructions, like jog x forward etc.

Maybe you can use ethercat bus as a server? Just add a slave that is your gui.