Trajectory Planner using Ruckig Lib
The product is about 4mm width on x axis and less then 3mm on y axis. So very tiny product dimensions.
I can not run on realtime kernel now, otherwise i could jog to measure the grid size.
Please Log in or Create an account to join the conversation.
The product is about 4mm width on x axis and less then 3mm on y axis.
Oh my, that is really tiny. Well, that puts my mind to rest and I can go to sleep now.
Thanks for putting up with my constant niggling.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Really keen to see this running.
Please Log in or Create an account to join the conversation.
Thank you !
I made a short video how it runs on the boomerang gcode file, i enabled using the scurve velocity ends in the kernel code :
I think it run's quite good for a first test.
I removed the boomerang preview (released opencascade memory), to get the gui more responsive. I made a button for this.
During screen recording, the gui even becomes slower.
Removing the boomerang preview works great, however i am thinking when running huge files, to show only a certain portion of the
gcode file.
Like 100 lines before and 100 lines after the current executed gcode line.
Furthermore i can optimize the opencascade memory, to show a memory efficient shape, like a memory efficient linestrip over the path,
this then for huge files like >10000 lines.
Please Log in or Create an account to join the conversation.
How do you set the feed rate? Is there a feed rate override function built in?
Please Log in or Create an account to join the conversation.
The feedrate is set from -100 to 0 to 100 % in the gui. It's like adaptive feed.
I have to add a overide like up to 120%, but that's peanut's to do.
If the feedrate is set at 100% the gcode feedrate is exact that value. For jogging it takes the gui settings page feedrate.
So at -100% the motion goe's in reverse, also doing reverse with endvelocity. Taking the vo as endvel.
Testing a surface, this file is huge so i did a memory preview cleanup first :
Ok after testing a few gcode files, i have seen a few things in the optimizing algo. I will document these and report.
Please Log in or Create an account to join the conversation.
I had to review some path blend code. Step by step, we go forward.
This is a tiny example how to use path blend, tooldir blend, & 3d velocity profile together.
The begin of something good maybe... I am still working on the tooldir, this needs some code review
here and there.
I did a test on the parport production machine, to test the velocity profile. The machine
or my pc is unable to perform a nice 9 axis job. As a result of that,
i am planning to run an ethercat production machine coming day's. This machine still uses stepgen.
However, best is to send just the coordinates to a servo drive. That saves the pc a huge ammount of
calculation time over 9 scurve axis.
Please Log in or Create an account to join the conversation.
However, best is to send just the coordinates to a servo drive. That saves the pc a huge ammount of
calculation time over 9 scurve axis.
I was under the impression that most of this could be done outside of the realtime thread. The filleting algorithm for example, couldn't that run before actual gcode execution?
Please Log in or Create an account to join the conversation.
I was under the impression that most of this could be done outside of the realtime thread. The filleting algorithm for example, couldn't that run before actual gcode execution?
Yes, all that is done before gcode execution.
It's just the parport machine that run's not good on hal-core.
Now halcore run's a test board with 2 ethercat steppers for x & y axis. But motor's run only very slow.
So i have to figur out what's the problem again.
Will install a new iso on hard disk, then try to run linuxcnc with ethercat. This is tested ok on the testboard
in the past.
Please Log in or Create an account to join the conversation.