Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
disentangling the trajectory planner API #476
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):
Plan: make those get_* callbacks to fetch values as needed
read-only - plan: make those getter callbacks:
read-write - make those getter/setter callback pairs; I guess these are must-have callbacks:
write-only - make those setters, ignoring them if NULL callbacks
velocity and acceleration bounds from emcmot_joint_t:
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.
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).
happy to report a milestone: disentangling complete and we're still above water.. meaning:
the tp and kinematics are now
the axis_mm.ini demo still runs no, noticable hiccups yet
vtp and kinematics are the RT module for trajectory planner and kins respectively
mah@nwheezy:~/machinekit-polish/src$ halcmd -f -k
halcmd: show vtable
thanks! looks like a script job to me; must extract the name of the kinematics, example changes:
or other kinematics:
When you need a testing gnome, give a yell and I'll rebase onto your branch and run my machine
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
I admit I am late on documentation but the gist is this:
summary: build a separate tp module which does a hal_init() but retain the code from tpmain.c (hal_export_vtable..)
hope this gets the idea across, let me know if you need a more detailed example
good luck, - Michael
also, this vtable example might help: https://github.com/machinekit/machinekit/tree/master/src/hal/vtable-example
I'm working on this. And, is studying the github work-flow.
ARAIS ROBOT TECHNOLOGY
On Thu, Mar 26, 2015 at 3:05 PM, Michael Haberler email@example.com
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)