Trajectory Planner using Ruckig Lib

Are you still working on the trajectory planner or has that project been shelved?

say it isn't so!

The thread does seem to have drifted a bit off topic.

Hi all,

The planner is not on the shelf. Soon i will work on it.
I am glad the planner worked on a real machine and did it's job.
However i needed some time to figur out some other things that got my interests.

Will add another topic for the latest posts.
 

let the guy have a firkin vacation! Yeesh!













... is it done yet?

Hi all,

I moved the discussion to a new topic, as the name of this topic is obsolete.
For further discussion's please visit:
forum.linuxcnc.org/38-general-linuxcnc-q...c-trajectory-planner

What about the socket server can you make another topic to follow up, it is interesting.

superimposed control
there are alot of multi turret and multi spindle lathes about now, old controls etc so needing some love of a new control , but to get the best from them you need run multi programs at once, superimposed if machine layout allows etc.
more so when you want to use two turrets on the main and do "pinch turning"
with super imposed you can offset pinch turn also so one tool will be slighly infront of the 2nd tool doing the finish.

you can start to do machines like this


this is superimposed control, where other axis sets must follow a master
basicly you "offset" the slave X Y Z to the master X Y Z which gives you axis following each other as you see.

yes there are macros that you call todo all this, (citizen call these sync codes) but its only setting up the system to group axis for use in each program, defind what will follow what and who and how.

the macro will also postion the machine in place for you to a setup drive on point. so the operators never see anything complex and scary to program as its been done for them interms of axis selection
you just program as if it was a normal X Z lathe.

i only have back ground on citizen machiens which have a lot of macros todo this alot of this, but have a good back ground how its basicly working things in the back ground. i think star has a different way todo things in terms of sync codes but i dont know never seen a program for one etc.

here is a video of my M20 sliding head Citizen, quick part i had to make.



here is a video of the program running



here you have 3 programs that run together using sync codes and wait codes.
these are kept in 1 file on citizens they just define each program by a $ sign for each program start $1,$2,$3 , when loaded on machine its displayed as 3 programs as seen in the video

here main slid on main spindle is working at its own speed while bottom turret is working on back end of the part in the sub spindle

once done, it waits for the main to be ready for turret to work on the main (you can use turret and main slid at the same time also, also can use the turret to say drill/bore on main and sub can drill or bore on turret also)

@Robh,

superimposed control.

Rob, you inspired me. It's really fun to get this running.
Now i let it run for a few hours. Everything goes well. Mutexes are set correclty.

Here it runs a example of 3 interpreters :
- Master interpreter xyz
- Sub interpreter abc
- Sub interpreter uvw

The master interpreter is sending programs to the sub's.
There can be set a flag that master should wait for sub to complete.
Without the flag set in the gcode, the sub will just run without callback.

 

Altough i have still a question.
At wich point path optimisation is the best to do?
Is this outside the while loops? Outside every command like WHILE, GOTO, IF, etc.
What do you think about it?

Specs super imposed interpreter library :
Load multiple (sub)interpreter in a pool.
Every interpreter run's in it's own thread pool. (multi threading)
Variables, conditions, expressions are solved by the mu::parser library.
Support for nested while loops, if goto, and a few others. Not complete yet.
Adjustable buffer, cq queue size.
Machine callback function. Machine sends ok to recieve next gcode line.



source codeberg
 

Hi Robh,

I was reviewing the video and saw something was not ok in the output.
Here is a revised video.

It shows clearly the waitcomplete cycle at the abc interpreter.
And shows the internal updated variable list, wich is interesting to evaluate.



readme how it works

Your comments about path offset given a value, is interesting.
To work with multiple tools on the same path, given a offset.

Have to think about how to achieve this.

The idea so far is to use the super imposed interpreter as a front end solution.
Wich now simplyfies the source code drasticly.
Path planning, etc. is then done by the machine controller itself.

Then for a path offset, we could pass a gcode or mcode from the super imposed interpreter to
the machine controllers, telling it to one controller stay behind the tp given a offset.

When working with multiple tools on the same path,  a collision detection in the form of boundary boxes
is no prohibited luxury.

Greetings.