Trajectory Planner using Ruckig Lib

More
06 Aug 2024 10:47 #307070 by Grotius
Hi,

I found out the problem.

This is a test board i made a few years ago. It uses ethercat and drives stepper motors.
 

I found out that i can run the testboard on hal-core with a sample script.
This scripts only load's the stepgen.so and the lcec.so. It drives just one motor.
When i set a new position using halcmd : ./halcmd setp stepgen.0.position-cmd 1000
It runs to that position, as it should. The stepper sounds nice, and is quick.

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.

Then we have to pin point where the time consumers are located in the trajectory planner.
So far i am happy that the ethercat works ok.

Running on : 6.1.0-23-rt-amd64

Warning: Spoiler!

 
Attachments:
The following user(s) said Thank You: tommylight, Lcvette, vmihalca, Darium

Please Log in or Create an account to join the conversation.

More
07 Aug 2024 04:11 #307139 by Lcvette
This is looking amazing!   I am impressed with how smooth that boomerang video looked!  Absolutely fantastic work my friend!  Thank you very very much for your hard work! 

Chris
The following user(s) said Thank You: Grotius

Please Log in or Create an account to join the conversation.

More
07 Aug 2024 08:45 #307158 by vmihalca

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. 
The following user(s) said Thank You: Grotius

Please Log in or Create an account to join the conversation.

More
09 Aug 2024 08:32 #307303 by Grotius
@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 :
Warning: Spoiler!


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.


 
The following user(s) said Thank You: Lcvette

Please Log in or Create an account to join the conversation.

More
09 Aug 2024 08:45 - 09 Aug 2024 08:49 #307304 by vmihalca
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.
Last edit: 09 Aug 2024 08:49 by vmihalca.
The following user(s) said Thank You: Lcvette, Grotius

Please Log in or Create an account to join the conversation.

More
09 Aug 2024 09:01 #307305 by vmihalca
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.
The following user(s) said Thank You: Grotius

Please Log in or Create an account to join the conversation.

More
09 Aug 2024 09:04 #307306 by Grotius
@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.
 
The following user(s) said Thank You: Lcvette, vmihalca

Please Log in or Create an account to join the conversation.

More
09 Aug 2024 09:22 #307311 by Grotius
@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.




 
The following user(s) said Thank You: Lcvette

Please Log in or Create an account to join the conversation.

More
09 Aug 2024 09:27 #307313 by vmihalca
Your maths knowledge is light years away from mine. Yesterday evening I was looking at YT videos about splines, with complex equations that are giving my brain stack overflow. You not only that you understood those, but you translated them to code and algorithms...That's a lot!

I pulled the OpenCN code back then and tried to run it but I had no ethercat hardware so it was just simulated.

I don't know how they have handled your challenges on getting the optimal velocity profile for a trajectory. I was in contact with them and I could get you in contact with them.
I know I was reading a while ago that the solution for having jerk control in linuxcnc was to use some sort of mathlab algortithm to do some complex calculations, but there was a licensing problem between linuxcnc and mathlab. Since the guys from OpenCN have behind an university, they had the mathlab with an expensive license on which they were able to generate that c/c++ algorithm.

I might be talking BS, but this is what I understood at that time. Clearly you are way more aware of the limitations than I am.

I could be efficient with the controller part and I would love to do that, but first I need a solid foundation to build upon.
The following user(s) said Thank You: Lcvette

Please Log in or Create an account to join the conversation.

More
09 Aug 2024 09:33 - 09 Aug 2024 09:35 #307315 by vmihalca

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.

My initial controller app for my lathe was written in kotlin multiplatform. 
Starting from a java project called JCNC Screen, I've build the JNI layer to talk nml with linuxcnc then build the rest of the UI on top of that with.
I abandoned that project for now because linuxcnc has an internal interpreter and an external interpreter. I was using the external one to get the cannonical motions, but the external one does not quite match the internal one. So I might end up drawing things that are not what the machine will do in the reality. I found this issue very problematic and this is where I bumped into how spagetti linuxcnc codebase is. 
I would love to revive this project, but as I said, I need a good foundation and I was hoping OpenCN to be just that, but without spindle sync, I would make my lathe not functional. And unfortunately, I don't have the knowledge (yet) or time to learn and do it myself.
Last edit: 09 Aug 2024 09:35 by vmihalca.
The following user(s) said Thank You: Lcvette

Please Log in or Create an account to join the conversation.

Time to create page: 0.161 seconds
Powered by Kunena Forum