Trajectory Planner using Ruckig Lib
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
#!/usr/bin/bash
# This test is verified ok, 6 august 2024.
cd ../../../../
echo $(pwd)
PWD_DIR=$(pwd)
# Find libhalcor.so in the ~/lib dir.
sudo ldconfig $PWD_DIR/lib
cd bin
./halclean
./halcmd stop
./halcmd loadrt threads name1=base-thread fp1=0 period1=30000 name2=servo-thread period2=1000000
# Unix command to load the ethercat .xml config
$PWD_DIR/rtlib/./lcec_conf $PWD_DIR/rtlib/ethercat-conf.xml &
./halcmd loadrt lcec
./halcmd net ec-slaves-responding lcec.slaves-responding
./halcmd net ec-link-up lcec.link-up
./halcmd net ec-all-op lcec.all-op
./halcmd addf lcec.read-all base-thread
./halcmd addf lcec.write-all base-thread
./halcmd start
./halcmd show
./halcmd loadrt stepgen step_type=0
./halcmd addf stepgen.make-pulses base-thread
./halcmd addf stepgen.capture-position servo-thread
./halcmd addf stepgen.update-freq servo-thread
# X-AXIS #######################################################
./halcmd setp stepgen.0.position-scale 265.3
./halcmd setp stepgen.0.steplen 1
./halcmd setp stepgen.0.stepspace 1
./halcmd setp stepgen.0.dirhold 15000
./halcmd setp stepgen.0.dirsetup 15000
./halcmd setp stepgen.0.maxaccel 1000
./halcmd setp stepgen.0.enable 1
./halcmd net xstep stepgen.0.step
./halcmd net xdir stepgen.0.dir
## Calculation ##
# drive : 5000 steps / rev
# pitch : 4 mm / rev
# calcutation : 5000 / 4 =
# scale = 1250
./halcmd net xstep lcec.0.output_stepper_1.dout-0
./halcmd net xdir lcec.0.output_stepper_1.dout-1
./halcmd setp lcec.0.output_stepper_1.dout-0-invert 0
# Then to run the motor cd to the ~/bin dir, then:
# ./halcmd setp stepgen.0.position-cmd 1000
Attachments:
Please Log in or Create an account to join the conversation.
Chris
Please Log in or Create an account to join the conversation.
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.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.
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.
Please Log in or Create an account to join the conversation.
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 :
#!/bin/bash
echo $(pwd)
PWD_DIR=$(pwd)
# Load the ethercat 4 axis config :
cd .. # ~/hal-core
cd src/hal/components/ethercat/
./runtest_4_axis_state_machine
cd $PWD_DIR
./cnc
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.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
My initial controller app for my lathe was written in kotlin multiplatform.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.
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.
Please Log in or Create an account to join the conversation.