disentangling the trajectory planner API

[mhaberler]

The emc/tp code needs access to some config and status items. This is currently done by referencing the emcmot_config_t, emcmot_status_t and emcmot_joint_t structures directly. This is undesirable as it creates a data structure dependency, and makes decoupling harder.

The idea is to replace those references by callbacks which go through a struct passed down from using code; the tp would get/set values as needed through these callbacks. If a callback is NULL for a readonly value, a default value could be used instead.

These are the items referenced:

num_dio, num_aio - setup time, read-only - pass as parameters once

emcmot_config_t (all read-only):
maxFeedScale double
arcBlendGapCycles double
arcBlendOptDepth int
arcBlendEnable int
arcBlendRampFreq double
arcBlendFallbackEnable int

Plan: make those get_* callbacks to fetch values as needed
Q1: do we need for changing these values on the fly? (like making them a pin/config item?)
Q2: if callbacks not set, what would be sensible default values?

emcmot_status_t

read-only - plan: make those getter callbacks:
net_feed_scale
spindleRevs
spindle.direction
enables_new
spindle_is_atspeed
spindleSpeedIn
Q: any sensible default values for the above?

read-write - make those getter/setter callback pairs; I guess these are must-have callbacks:
spindleSync
current_vel
dtg
spindle_index_enable
spindleSync

write-only - make those setters, ignoring them if NULL callbacks
requested_vel
distance_to_go
spindle.speed
enables_queued

velocity and acceleration bounds from emcmot_joint_t:
these look like config-time fixed (or does it make sense have those changeable on the fly?)
tpGetMachineAccelBounds(PmCartesian * const acc_bound)
tpGetMachineVelBounds(PmCartesian * const vel_bound)

the alternative to a table of getters/setters would be to provide pointers to the raw data (wherever that lives) decoupled from the actual structures; while simpler, we dont get change notification in the using code - the callback scheme would allow tacking an action onto any change

another method would be to move these items into the tp instance data, and provide getters/setters for the using code

what is preferrable: callbacks, data reference or make it instance data?

it's also conceivable to use a combination; e.g an using-code accessor for say current_vel, requested_vel etc; and callbacks for spindle* values which change rarely.

[mhaberler]

ok, plans revised. On the spectrum "proper class encapsulation" to "best HAL integration" I'd go for the latter and handle all these variables as potential HAL pins (they easily can, but they do not have to be pins). It would mean tp becomes HAL-aware, which it currently is not. It would mean value access is by direct data reference, not getters/setters. There can still be "change callbacks" out of tp, but they might be optional (NULL allowed).

this means: all shared variables and parameters become hal_s32_t * and hal_float_t * pointers in a struct which will be allocated via hal_malloc() at tpInit() time. This should also be compatible with future configItems once we have them (it might mean configItem values need to live in the HAL shm segment).

[mhaberler]

happy to report a milestone: disentangling complete and we're still above water.. meaning:

the tp and kinematics are now

• loadable (more than one!)
• referenced through a named vtable meaning there can be an arbitrary number of kins and tp's loaded (this is how the API is exported: https://github.com/mhaberler/machinekit/blob/vtable-tp-and-kins/src/emc/tp/tpmain.c ; typedefs are here: https://github.com/mhaberler/machinekit/blob/vtable-tp-and-kins/src/emc/tp/tp.h, usage example: https://github.com/mhaberler/machinekit/blob/vtable-tp-and-kins/src/emc/motion/motion.c#L1186-L1192
• have ZERO knowledge about motion internals (the emcmot* structures) - everything goes through the tp_shared_t struct (https://github.com/mhaberler/machinekit/blob/vtable-tp-and-kins/src/emc/tp/tp_shared.h), hence the tp can now be used in a non-motmod environment (!) - here is how the shared state is tied into the legacy motmod structs: https://github.com/mhaberler/machinekit/blob/vtable-tp-and-kins/src/emc/motion/motion.c#L1384-L1455

the axis_mm.ini demo still runs no, noticable hiccups yet

vtp and kinematics are the RT module for trajectory planner and kins respectively
in the 'show vtable' section you see the named vtable objects which are referenced by motion (refcnt 1)

mah@nwheezy:~/machinekit-polish/src$ halcmd -f -k
halcmd: show comp
Loaded HAL Components:
ID Type Name PID State
748 User halcmd7233 7233 ready, u1:0 u2:0
732 User axisui 7207 ready, u1:0 u2:0
663 User inihal 7206 ready, u1:0 u2:0
628 RT comp RT ready, u1:0 u2:0
621 RT or2 RT ready, u1:0 u2:0
610 User hal_manualtoolchange 7192 ready, u1:0 u2:0
593 RT near RT ready, u1:0 u2:0
585 RT lowpass RT ready, u1:0 u2:0
575 RT limit2 RT ready, u1:0 u2:0
567 RT sim_spindle RT ready, u1:0 u2:0
536 RT hypot RT ready, u1:0 u2:0
505 RT ddt RT ready, u1:0 u2:0
272 RT motmod RT ready, u1:0 u2:0
270 RT vtp RT ready, u1:0 u2:0
268 RT trivkins RT ready, u1:0 u2:0
89 User halui 7173 ready, u1:0 u2:0
71 User iocontrol 7169 ready, u1:0 u2:0

halcmd: show vtable
Exported vtables:
ID Name Version Refcnt Context Owner
271 tp 2000 1 RT 270 vtp
269 trivkins 1000 1 RT 268 trivkins

halcmd:

cleaned branch: https://github.com/mhaberler/machinekit/tree/vtable-tp-and-kins-try2

[mhaberler]

made a PR: #501 - looks stable but the shit job is still ahead: modifying 205 .hal files to add "loadrt tp" :-/

[luminize]

I'll help, let's split the job

On 21 Feb 2015, at 22:33, Michael Haberler notifications@github.com wrote:

made a PR: #498 - looks stable but the shit job is still ahead: modifying 205 .hal files to add "loadrt tp" :-/

—
Reply to this email directly or view it on GitHub.

[mhaberler]

thanks! looks like a script job to me; must extract the name of the kinematics, example changes:

before:

# kinematics
loadrt trivkins
# motion controller, get name and thread periods from ini file
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES

after:

# kinematics
loadrt trivkins
# trajectory planner
loadrt tp
# motion controller, get name and thread periods from ini file
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES tp=tp kins=trivkins

or other kinematics:

# kinematics
loadrt pumakins
# motion controller, get name and thread periods from ini file
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES

after:

# kinematics
loadrt pumakins
# trajectory planner
loadrt tp
# motion controller, get name and thread periods from ini file
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES tp=tp kins=pumakins

[mhaberler]

it's just 107 files after all:

 find configs/ -name '*.hal' -print|xargs grep EMCMOT|grep -v tp=tp|cut -d ':' -f1

[luminize]

When you need a testing gnome, give a yell and I'll rebase onto your branch and run my machine

On 22 Feb 2015, at 07:16, Michael Haberler notifications@github.com wrote:

it's just 107 files after all:

find configs/ -name '*.hal' -print|xargs grep EMCMOT|grep -v tp=tp|cut -d ':' -f1
—
Reply to this email directly or view it on GitHub.

[mhaberler]

Actually I'd appreciate that very much, the bbot seems to be wedged

the https://github.com/mhaberler/machinekit/tree/vtable-tp-and-kins-try2 branch should be up-to-date relative to master

the only change you need for your config is the one mentioned above: loadrt tp, and add the tp=tp kins= incantation to the loadrt motmod line

[yishinli]

Do you have an example HAL file that loads more than 1 tp?
I'd like to learn how to instantiate 2 tps in one machine.
Thanks.

[mhaberler]

Hi Yishin,

I admit I am late on documentation but the gist is this:

• a HAL vtable is really just a named pointer with a type ID (the version) and used to refer to a jump table like in tpmain.c
• modules need to have different names, so you new tp should not be named "tp"
• if the api (signatures and number of functions) is the same as the old tp you could use the same version (version is intended to prevent accidentially connecting using code to exporting code with a different API)

summary: build a separate tp module which does a hal_init() but retain the code from tpmain.c (hal_export_vtable..)
in the using code, refer to the vtable by name and API version, - just grep for vtable in the emc/motion directory to see how its imported

hope this gets the idea across, let me know if you need a more detailed example

good luck, - Michael

[mhaberler]

also, this vtable example might help: https://github.com/machinekit/machinekit/tree/master/src/hal/vtable-example

[yishinli]

Hi Michael,

I'm working on this. And, is studying the github work-flow.
Will inform you if I get any progress.

Regards,

Yishin

ARAIS ROBOT TECHNOLOGY
www.araisrobo.com
TEL: +886-2-8919-1239

On Thu, Mar 26, 2015 at 3:05 PM, Michael Haberler notifications@github.com
wrote:

also, this vtable example might help:
https://github.com/machinekit/machinekit/tree/master/src/hal/vtable-example

—
Reply to this email directly or view it on GitHub
#476 (comment)
.

[yishinli]

In order to have 2 independent TPs for 1 machine, I will need to load the following modules:

• 2 TP modules with different module name
• 2 kinematic modules
• 2 emcmot modules

Is my understanding correct?
-Yishin

[mhaberler]

• yes, 2 TP modules with different module names
• no, kinematics are reusable, those are done via vtables as well! more than one using comp may use a vtable (which is just the comps functions exported in a different way
• motmod is stupidly a singleton so cant do that, and it also believes it just has to create threads

we need to fix the latter beforehand; note also the linuxcnc using layer (task etc) has NO idea that there could be more than one motion (maybe some hack with SHMKEY is possible)

[mhaberler]

I guess that wasnt totally helpful ;) what you CAN do is use several different TP's and kins from motion!

[yishinli]

Thanks, I believe that is the solution.
What I'm going to do is identical to one of the application stated on the Machinekit Blog Loadable Trajectory Modules.

Maybe your robot arm also has a gimbal mounted camera you want to control independently