Trajectory Planner using Ruckig Lib

Hi Arciera,

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.

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.

A boomerang test file :
 

fillets 0.01mm
 

fillets 0.1mm
 

green is an arc, its a cut off for the boomerang tip shape.
purple is clothoid fillets.
cyan is spline fillets.
white is line.

vel profiles G64 P0
 

vel profiles G64 P0.01
 

vel profiles G64 P0.1
 

That's amazing Grotius!

Really keen to see this running.

Hi Becksvill,

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.



 

Very nice! Congratulations.
How do you set the feed rate? Is there a feed rate override function built in?

Hi Arciera,

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.

Hi,

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.

 

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?

Hi Arciera,

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.