LinuxCNC S-Curve Accelerations

Hi Grotius,
look at this link:
github.com/parhansson/KMotionX/blob/mast...oryPlanner.cpp#L2181

Given a "segment" with "s", "vo", "vm", "ve", "a", it will calculate 3 polynomials and their execution times. If the execution time is 0, that polynomial is not executed.
-automata

Hi,

That's correct, if vm=0, it will do nothing. Also if a=0 (acc) or d=0 (dcc), it will do nothing.

The code over there does not include stages like, what to do if vm can not be reached during the move?
Do we need to sample? What to do if ve can not be reached given a displacement?

The comments also confirm this :The above sequence is performed for long moves where maximum(and constant) velocity is achieved.

For the scurve creation i use formula's from papers like : github.com/grotius-cnc/scurve-pro/blob/main/science_paper_0.pdf

Hi Andy, did you mean the smp motion planner? Or is question related to other motion planners?

Hi Andy,

Is your module usable for this?
The scurve motion planner on my github misses one thing. A live motion planning capability.
When this works, it could be made lcnc pluggable.

I looked to your provided links. What would be the fastest way to make it pluggable?
I have no clue where to start with this. My original idea was to make a halcomponent motion planner.

Currently working to get the scurve running in live mode.
Now the smp planner (conventional trapezium) planner works, i can use that in combination to calculate motion blocks.

I now have 2 classes :
1. smp (simple motion planner). This one works nice and does conventional trapezium motion solutions in live mode.
2. scp (simple curve planner), this one uses functions from the smp to avoid function duplication. The scp has
functions to create scurve's.

The scp uses a slightly different approach then the smp. I see no other solution.
The scurve has to be calculated on forehand. Only during intreruptions,
like a "vm" velocity max change, the motion is recalculated, respecting the current scurve acceleration value.

The smp can calculate the motion path each servo cycle, the scp can not do this, unless the "jm" should always have the
same value, but every curve has it's own "jm" value.

I hope it will work soon.








 

The Linuxcnc motion planner does not operate in real time.
Instead the gcode is parsed and tokenised into a buffer which is in turn consumed into machine motion in real time.
eg It is calculated beforehand  so your scp should be able to be incorporated.

> The Linuxcnc motion planner does not operate in real time.

This is incorrect and misleading -- likely
conflating the interpreter's processing of gcode
program commands with the trajectory planner's
processing of canonical commands.

Simplified overview (2.9 and up):

The interpreter in the task program (typ:
[TASK]TASK=milltask) processes gcode commands in
userspace to generate canonical (canon) messages
that are sent to the realtime motion module (typ:
[EMCMOT]EMCMOT=motmod)

canon Ref:
github.com/LinuxCNC/linuxcnc/blob/master...mc/nml_intf/canon.hh

The *realtime* motion module makes calls to the
trajectory planner (default: tpmod) at the servo rate
to blend and compute new positions based on the
machine configuration, the queue of canon
messages, the current position, instantaneous
requests (adaptive_feed for example), etc.

Ref: tpRunCycle invocation:
github.com/LinuxCNC/linuxcnc/blob/master...tion/control.c#L1327

The trajectory planner functions are named tp[A-Z]*
The trajectory planner interface is defined in tp.h,tc.h

Ref:
github.com/LinuxCNC/linuxcnc/blob/master/src/emc/tp/tc.h
github.com/LinuxCNC/linuxcnc/blob/master/src/emc/tp/tc.h

Note: that alternative trajectory planning modules
can be built with halcompile following the
instructions in tpcomp.comp

Ref: github.com/LinuxCNC/linuxcnc/blob/master...mponents/tpcomp.comp

*All* tp interface functions must be provided.
However, a custom planner can add or remove
functionality.

For instance, a custom planner could implement 3D
planning but provide jerk limiting for 2 axes only
(a boon for plasma cutters probably but much
simpler than a higher degree planner).

Similarly, a custom planner could sacrifice the
provisions for rigid tapping or the ability to
accept realtime feed overrides.

The trajectory planning module (tpmod) implements 29 functions:

 

Hi Mr. Garret,

Thanks for the detailed explanation.

I expect the scurve motion planner with live mode can be ready within a few day's.
Have to code the motion solver and a few tiny things. Most of the function's are there.
Just updated code:
github.com/grotius-cnc/motion_tryout/blob/main/scp.h

A few questions about a possible scurve lcnc integration :

1. Has someone already code a sample motion component to use with lcnc, so we can take a look how it's done?
2. Is there a example, like a patch, or file replacement to show what's needed and where?
3. If there was a template component available, user could just make a motion connection from there.
4. My original idea was to write a motion component, this includes gcode reader etc. How do you think about this option?
Personally i don't like the idea to rely on Python and the Python opengl graphics that are buried in lcnc so deep no one is able
to get a hand on it.

> A few questions about a possible scurve lcnc integration :

> 1. Has someone already code a sample motion component to use
> with lcnc, so we can take a look how it's done?
> ...

Not sure what is meant by 'motion component' as the phrase
could be interpreted in several ways. Perhaps you could
use ini file terminology described in the 'Terminology
Summary' (below) to clarify.

> 4. My original idea was to write a motion component, this
> includes gcode reader etc. How do you think about this
> option?

LinuxCNC supplies a default userspace gcode interpreter as
part of the userspace 'milltask' program with a provision to
specify an alternative gcode interpeter (see [TASK]TASK
below). Reading gcode in a realtime motion context would be
a different design architecture than that used by the
existing LinuxCNC design.

> Personally i don't like the idea to rely on Python and the
> Python opengl graphics that are buried in lcnc so deep no
> one is able to get a hand on it.

No use of python or OpenGL is required anywhere but many
of the available display interfaces use these common software
tools (see [DISPLAY]DISPLAY below).

A==========================================================
Terminology Summary

Some [SECTION]VARIABLE nomenclature used throughout LinuxCNC
as based on ini configuration file settings

B==========================================================
Userspace programs ini file settings

[TASK]TASK=milltask
Specifies a primary userspace program. The program named
'milltask' is the default LinuxCNC userspace program that
includes a gcode interpreter and interfaces to other
userspace programs (typ: io, display), and the realtime
motion module and HAL (the Hardware Abstraction Layer). The
'milltask' program can optionally invoke an alternative
interpreter using the ini file setting: [TASK]INTERPRETER.
A skeleton example interpreter is provided (canterp).

[DISPLAY]DISPLAY=display_program_name
Specifes a program that typically provides a user interface
(ui,gui). There is no default but numerous programs are
available within the LinuxCNC tree and some written by other
developers. A DISPLAY program may use graphics without
OpenGL (example touchy, tklinuxcnc) or graphics with OpenGL
(examples: axis, gmoccapy, qtvcp). A DISPLAY program can be
an executable or script. No use of graphics is required
(see: halui) and remote DISPLAY interfaces are possible
(see: linuxcncrsh). The DISPLAY program can interact with
other LinuxCNC programs (typ: io, milltask) and with the
realtime motion module and HAL .

C)==========================================================
Realtime modules ini file settings:

[EMCMOT]EMCMOT=motmod [parameters ...]
Specifes the realtime motion module. The module named
'motmod' is the default LinuxCNC motion module. The motmod
module calls other realtime modules that must be loaded
prior to its loading:
a) homing (default=homemod)
b) trajectory planning (default=tpmod)
c) kinematics (no default)
In addition to its interfaces with the above modules, the
default 'motmod' module receives messages from the userspace
task program (typ: [TASK]TASK=milltask) and interacts
with HAL (Hardware-Abstraction-Layer).

[TRAJ]TPMOD=custom_trajectory_planner [optional_parameters ...]
Specifies a trajectory planning module. If omitted (the
usual case), the default module 'tpmod' is used. A custom
module can be built with halcompile. A skeleton example is
provided (tpcomp.comp).

[EMCMOT]HOMEMOD=custom_homing_module [optional_parameters ...]
Specifies a homing module. If omitted (the usual case), the
default module 'homemod' is used. A custom module can be
built with halcompile. A skeleton example is provided
(homecomp.comp).

[KINEMATICS]KINS=module_name [optional_parameters ...]
[KINS]JOINTS=number_of_joints
A kinematics module (no default) is specified according to
the machine configuration. A kinematics module may be
designed to support a discretionary numbers of joints so it
is necessary to also specify the number_of_joints. Many
common machines use identity kinematics and invoke the
provided trivkins module. The trivkins name is short for
trivial (identity) kinematics.

D===========================================================
Notes:

1) The loading of the default trajectory planning module
(tpmod) and the default homing module (homemod) are handled
by the linuxcnc script with no need for the ini file
settings [TRAJ]TPMOD, [EMCMOT]HOMEMOD.

2) The homing and trajectory planner modules can also be
specified with command line options for the linuxcnc script
(see $ linuxcnc -h)

3) The kinematics module specified with ini file setting
[KINS]KINEMATICS and the motion module specified by
[EMCMOT]EMCMOT are typically loaded in the required order
by an ini file specified [HAL]HALFILE that includes lines
like:

...
loadrt [KINS]KINEMATICS ...
loadrt [EMCMOT]EMCMOT num_joints=[KINS]JOINTS ...
...

4===========================================================
Refs:

4) ini file configuration:
linuxcnc.org/docs/devel/html/config/ini-config.html

5) custom trajectory planning module skeleton:
github.com/LinuxCNC/linuxcnc/blob/master...mponents/tpcomp.comp

6) custom homing module skeleton:
github.com/LinuxCNC/linuxcnc/blob/master...onents/homecomp.comp

7) motmod objects:
github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L1192

8) canterp alternative interpeter:
github.com/LinuxCNC/linuxcnc/blob/master...c/canterp/canterp.cc

9) halui
github.com/LinuxCNC/linuxcnc/blob/master...mc/usr_intf/halui.cc

10) linuxcncrsh (naming reflects emc legacy):
github.com/LinuxCNC/linuxcnc/blob/master...c/usr_intf/emcrsh.cc