Trajectory Planner using Ruckig Lib

Hi,

Did some work on the super imposed interpreter code again.

It's now able to do more things like : stop, restart at line, set variable at runtime.

The video show's basic functionality. And show how sub interpreters may run their own program.

There is a machine-consume button, wich simulates the motion planner takes lines of gcode from the interpreter output buffer.
The delay input's slow's down the simulation wich enables us to view the step's the interpreter does.

Have to make the qt layout more fancy.

that is awesome, for some reason multi spindle swiss machine just popped into my head looking at that. I have been watching to many Tornos videos drooling lol

Thank you Collins.

Attached video shows the 3 interpreters tools moving around.

There is no motion component or whatever. The tool is just jumping to the consumed gcode position.

One of the problem's is when adding gcode segments to a infinite program, it has to check for duplicates,
and there must be a limit to the gcode preview. Otherwise we get a buffer overflow.

This run's quite stable, fixed some runtime bug's.

that's cool

Hi Collins,

Today was a good day for coding. This morning still had a crash problem for the interpreter.
For the colors of the code i thought, RGB, red, green, blue.

Now the super imposed interpreter is running ok.

Added the realtime environment : base-thread & servo thread is loaded and running.

The servo-thread has now 3 motion components running. This is really cool.

libmotion_0.so -> produces motion for main interpreter (red)
libmotion_1.so -> produces motion for sub_0 interpreter (green)
libmotion_2.so -> produces motion for sub_1 interpreter (blue)

The idea is then to send the interpreter's gcode output to the motion components over the 1ms thread.
We do this over shared_memory.

Then we have to code the motion components. They will use the scurve and toolpath optimalisation as seen before.

The base thread has the libethercat.so component running soon.   This has ethercat auto configuration.

This is going to be a cool winter project.

There are a few questions, like what if sub_0 interpreter is a tool changer. The green tool cone is then not valid.
Depending on the machine configuration, the green and or blue cone must be replaced by something else?

codeberg.org/skynet/realtime_app/src/branch/master

when this is done, this will be a huge optorunity for linuxcnc , how much of this code should be upstreamed to linuxcnc ?

Hi Collins,

It's far from linuxcnc compatible.
The hal works different and the rtapi works different.

The code is entirely different. The realtime approach is the same.

so is this going to be a linuxcnc alternative cnc controller?

Hi Lcvette,

It's indeed a alternative controller, once it finished.
This can take a long time. Some are good coding day's, some are bad coding day's without good progress.

It turned out, modifying lcnc's code to do thing's i would see accomplished is almost impossible.
Best reason is entanglement.
Then just writing new code from scratch is 10x faster to get things done.

There are no goals for me. It's just a project to try out new things wich got my interest's.

It's not the purpose to outsmart lcnc or something like that. Or claiming thing are better etc.

Altrough it is interesting to find out differences in lcnc and this approach.

Like this has bi-directional hal pins and used modern boost interprocess for shared memory.

Today did a mayor bug fix. It turn's out that multiple shared memory regions updated by thread's, would not exchange data
properly. Even when mutex etc. was set.
In the end it worked by using a single shared memory region for all thread's.

sorry not been here for awhile but life just got in the way, very bussy months here

looks like you have been bussy Grotius

dont forget with multi program running like i showed, its important that you dont tie each "interperter locekd to an axis group" becasue it needs to be far from it to be powerfull, any instanact should read any spindle feedback, know where other axis are so can follow them as a slave or master axis "offset" etc
so yes that a hal layer thing so hal can pass info between each other.

because each program group can and should be able to command other axis out side its "group" so program 2, shuld be able to move Z1 , so part can position from the guide bush. very much how you manage mode/group switching

ill try and find the page in one of my manuals for lathe and share will give you some ideas i think. better than many words, but abit like this...

while on swiss yes each "program instance" has an axis group set. i can change mode with a G code, like G710 etc (there are loads of these code sets) and it will control how these 3 programs interact together, you have to use same G710 setting code in all 3 or it alarms out

then control knows program 2 is now master , or program 3 is master etc realy which axis group the other 2 must be salved too..
(btw not all swiss etc have 3 heads, some only have 2, some have just 1)

eg
that way, you can program threading on program 1 , have X and Z do thread of a pitch say 1mm, while program 2 can also do threading, following Z in the program of Z1 but do a different pitch on Z2 of say 2mm , as it can read the spindle encoder also into both interpreters etc..,

on a fixed head lathe, you dont need to follow Z1 as your stock does not move,
unless your chasing the main turret with a sub spindle, while main turet works on front spindle like that miyano video.

yes you can bring in a sub for support and hold the part, and have Z3 follow Z1 while turret does what ever.. sounds complex but with simple switching etc becomes abit natral thinking on program layout etc for the siwss world of coding and setup.

but yes as you said making linuxcnc multi interpreter and multi hal is abig challenge many have looked at it before and no one has ever taken it on.

sorry for long reply