Trajectory Planner using Ruckig Lib

oooh

Grotius wrote:

Hi Guy's.

Nice discussion.

I finally found the G64 P & Q values for the trajectory planner.

The plan coming time is to integrate clodhoids into the linuxcnc interpreter.
The gcode name for clothoids is defined as G9.

So user can simply load his gcode file. We check if the file contains G64 params.
We then do G64 P&Q value optimalisation for entire gcode file, this is done offline.
Then we save the optimized gcode as a copy and load the copy into lcnc nml again.

The gcode is now reading the G9, the block is enchanged, checked, and now working on execute_block.
I will make notes on how to add stuff to the interpreter.

Earlyer today the repository is initialized from linuxcnc zero. You can now follow the commits i have done.
 

sweet!  however i might give an example that is closer to how cam pumps out gcode.  the G61/G64 often times is being swapped between. for example roughing strategies utilize G64 with larger P/Q values, while finishing operations will typically either use G61 or G64 with much smaller P/Q values.  it is not uncommon for a code file to have several changes between G64 and G61 also with many changes to the G64 P/Q.   Is the G9 going to specify only those section where G64 is located?

rodw wrote:

PCW wrote:

 but the tangential acceleration (acceleration in the line of motion)
is currently just set by an ini constant
That may not be correct. It certainly isn't for velocity. The ini file sets the velocity and acceleration for each joint. If a linear move is diagonal (where both X & Y axes contribute to the move),  The overall velocity (and probably the accelleration) is higher becasue  both axes are contributing to the move. I would expect the same applies to arcs where the motion at any point in time is tangential to the arc so resolving into X & Y forces will result in contribution by both X & Y axes which I would expect would  achieve the same result as a linear move.
 

I guess I should have said the tangential acceleration is currently just set by ini file constants.
 

Lcvette wrote:

it is not uncommon for a code file to have several changes between G64 and G61 also with many changes to the G64 P/Q. 

Good point.

Depending on the post, CAM posts I used for a couple different controllers (including LCNC) tends to use G61 for hole functions (drill/tap/ream), and a combo of G61/G64 with varying P/Q for roughing/finishing.

@Lcvette,

Is the G9 going to specify only those section where G64 is located?
For automation the G9 will be used to solve a gcode program using G64 P&Q values.
Then multiple G64 commands with different values in one gcode file are ok.
That's what is mentioned earlyer to deal with.

@All,
I have done a discovery. Was digging into how nurbs are processed. It turns out they are
loaded into the trajectory planner as a x number of arcs. So in fact the nurbs are transformed into
tiny arc segments.

I think it's better to interpolate nurbs, splines, etc by the trajectory planner itself.
This avoids tiny segments and is just more logical to do?

My plan is to certainly interpolate the tri-clothoids directly in the trajectory planner. So we add
a function : tpAddClothoids to this. And maybe also tpAddNurbs & tpAddCubicSpline etc.
It's also a idea to pass a general primitive like: tpAddItem(enum type); Where we just can load what
we want without messing with all kind of code.

I finally found how the interpreter rs274 is given the gcode to the realtime part of lcnc.

The interpreter is called by init(), read() etc. No problem.
Then the weird thing is, It calls function's that don't excists in the interpreter source itself.
That was the confusing part. I suspect you could name this callback functions.

The interpreter code will not compile without external program that has several interpreter functions declared.
For example, this function is not in the interpreter code : But it is called by the interpreter.

Then the milltask.so is the chain between the interpreter and the hal realtime part.
The hal realtime part is motmod.so, here it sends motion commands to the trajectory planner like : tpAddLine().. etc.

The interpreter has also a python interface, so the lcnc gui's can get the data to draw the opengl gremlin gcode.

Notes:
 

The plan now is to add a callback function to the interpreter for test  :
void TRI_CLOTHOID(){}
This then has to be added into the source up to the trajectory planner. Let's try this.

Linuxcnc is supposed to be a generic interpreter that allows certain modules to be replaced so you can run different languages in addition to gcode..
Milltask is a replaceable task module loaded in the .ini file refer /src/emc/task folder. But it it is the only task module ever written.  so it stands to reason that there are some specific functions in this module called by the system. What you called callbacks.

It was once suggested that there should be a plasmatask task module because plasma is so different to a milling machine...