joints-axes branch not yet merged

[ArcEye]

Issue by mhaberler
Wed Jan 14 23:56:29 2015
Originally opened as machinekit/machinekit#438

---

current code (mostly motion and jogging-related upper layers) has some fundamental confusion about axes versus joints. Cleaning this up is an important prerequisite for supporting non-trivial kinematics better, and also to clean up dark corners like jogging.

There has been work ongoing for several years mostly by Michal Geskiewicz to remedy this, it's in branches termed 'joints-axes' or 'jaX' both in git.linuxcnc.org and my own machinekit fork on github (possibly others too). The code is mostly in place, but bits and pieces are missing.

Of the options - have those branches linger around on end, or go for an accelerated merge with a likely bumpy period thereafter, I think the second option is the better (and motivation for fixes will be higher).

A likely base branch could be this: https://github.com/mhaberler/machinekit/tree/ja6-candidate-1 which rebases the git.linuxcnc.org ja6 branch onto machinekit while keeping the jog-while-paused feature working

[ArcEye]

Comment by mhaberler
Thu Jan 15 06:54:01 2015

---

problems which will likely pop up:

• Configuration changes needed (Andy's script will help)
• Documentation needs updating
• kinematics modules need KINEMATICS_BOTH to switch between axis+joint modes in manual
• jogging will need updated support in UI's
• jogging might need updated NML messages to carry axis jogs properly
• jogging more than one axis (e.g. diagonal) does work yet due to lacking NML support
• wheel jogging needs to be taught about axis jogs

[ArcEye]

Comment by luminize
Thu Jan 15 08:51:55 2015

---

Would you want me to split these in separate issues? For keeping focus and make the work more manageable?

On 15 Jan 2015, at 07:54, Michael Haberler notifications@github.com wrote:

problems which will likely pop up:

Configuration changes needed (Andy's script will help)
Documentation needs updating
kinematics modules need KINEMATICS_BOTH to switch between axis+joint modes in manual
jogging will need updated support in UI's
jogging might need updated NML messages to carry axis jogs properly
jogging more than one axis (e.g. diagonal) does work yet due to lacking NML support
wheel jogging needs to be taught about axis jogs
—
Reply to this email directly or view it on GitHub.

[ArcEye]

Comment by mhaberler
Thu Jan 15 09:31:54 2015

---

well it's roughly as I remember them; I'm not sure all of them are still present and relevant
I'd rather wait a bit until somebody gets onto the task and takes stock; then certainly it's a good idea to go for 'one each' to make sure they are addressed

[ArcEye]

Comment by mhaberler
Tue Jan 27 22:26:22 2015

---

I've learned some more parts are in the queue, and they relate to this issue:

• Michal Geskiewicz has been working on jerk-limited trajectory planning based on the old (pre-Ellenberg) planner, but including joints-axes mods (ja4); merging this code might involve significant testing and work
• Yishin Lin has been working on jerk-limited tp for a long time, and that code is already based on the Ellenberg tp modifications; merging might be easier wrt tp code but the status is unclear and it does NOT entail ja4 mods

so we need to decide which code and in which order, and in which relation to jaX (micges suggests: first jaX, then tp mods)
also we'd need a bit of support promise and docs

both projects suggest there be a method to runtime-load complex code pieces like a tp or kinematics, and multiple instances of those if possible; this suggests HAL support for a new kind of object (basically classes which are instantiable, but not components proper, and export a function switch table similar to the c++ vtable or the kernel's device switch; I am looking into that now

[ArcEye]

Comment by mhaberler
Mon Feb 2 19:41:34 2015

---

Michal has suggested that - either way - we first make tp a loadable module

in my never-ending quest for grandiose coding, I'm working on support for loading code which can be instantiated more than once like a class, and added HAL support to it (called HAL classes and vtables); some notes on the idea:

issue:

• right now loading say a kins module rests on load-time symbol resolution (kernel insmod or shared lib dlopen)
• that restricts loading to one-of-a-kind per process space (RT or userland thread) because symbol resolution happens only once - singletons only this way
• ideally we'd have multiple kins live and switchable, and loadable tp's (yishin flavor, micges flavor, robellenberg flavor etc etc ;)
• what these pieces export is a whole API (lots of functions), and sometimes a bit of data
• this is very close to what a C++ vtable does, or rtapi_switch_t does - basically a struct to dispatch functions to the currently loaded RT API; or to what a driver does with the device switch structure (open, close, read, write, ioctl etc); however rtapi is a singleton too - rtapi_switch is a pointer to the dispatch struct which is resolved at load time

approach:

• what the new object would do is export a named switch structure (like the emc/tp/tp.h API); the switch struct would consist of a stock struct at the beginning (name, type, version, refcount) and then function pointers (those are custom to the purpose, eg. one per tp API call)
• the object would have an associated signature field (basically a version ID of the switch struct) as a sanity check (C++ does handle this link-time with its funny signatures, but we're in C land and C dont, so we need a makeshift protection)
• since this is pretty much a class, I'd call it a HAL class for now, and the table a vtable
• technically vtables are first-order HAL objects with name and id, but for them to be useful they would be typically be exported by a component; so there's an optional comp_id param linking a vtable to a component
• loading a class would cause in rtapi_app_main to call to say hal_export_class(name, verson, vtable, component_id) which would generate the vtable object

using code (e.g. motion loading a tp or kins) would call hal_reference_class(name, version, **vtable) and return the class id and set vtable pointer; also increase the refcount

there'd be a matching hal_unreference_class(class_id) to drop the refcount; zero refcount permits unloading the class on rtapi_app_exit

plus some basic halcmd support to view the new objects in a sensible context

once using code has a handle on the switch struct, it would be able to reference say tp API functions by handle->tpFuncX(params..) just like the rtapi_switch does

the whole thing is pretty much a C++ vtable in C, with HAL loading draped around it; the intent is to have those modules instatiable right through the switch struct as designed (other than the hokey halcomps with their confused instance idea)

use case would be RT, but with a minor twist such classes could be loaded into a userland component as well (it would be private to the userland comp, and not callable from RT, also the other way around
this would allow to say load a tp or kins module either in RT or in userland as needed, I think that would help migrating such stuff out of RT

using code needs adapting from calling (params) to handle->(params); for tp that's some 30-40 refs or so, and for kins maybe 2, so much less than the RTAPI migration behind us

halcmd would list class names, comment string, version, refcount, RT (not sure if userland loaded classes should be registered in HAL since they'd be strictly process-local so no reuse or reference possible anyway)

note a HAL class does exactly nothing unless called through the switch struct, which includes instantiation; I'm not promising this be a way to migrate to instantiable comps but it's very close to this idea - separate instantiation from loading - besides exporting any kind of API regardless of the load-time symbol resolution restrictions

[ArcEye]

Comment by mhaberler
Mon Feb 2 22:46:12 2015

---

this branch adds the HAL library, and halcmd support for vtables (I dropped the pathetic 'class' name for what is essentially a typed, named, refcounted pointer intended for level 0 class support). Example included:

https://github.com/mhaberler/machinekit/commits/hal-vtable-support

Next step are:

• modulate the kinematics api to use vtables so several kins can be referenced
• then wrap the tp API into a vtable

(kins first since simpler API)

[ArcEye]

Comment by mhaberler
Tue Feb 3 00:54:09 2015

---

step 1 done - changed trivkins to vtable API: mhaberler/machinekit@51a2de3

changed motion to use it: mhaberler/machinekit@41db5a5

that looks like a pretty simple migration. TP next..

https://github.com/mhaberler/machinekit/commits/vtable-kins

[ArcEye]

Comment by mhaberler
Wed Feb 11 22:45:12 2015

---

status: halfway through disentangling emcmotstatus and emcmotconfig globals access in tp so the tp code can be compiled without referencing those structures

realistically I can get to it only 3rd week of Feb

[ArcEye]

Comment by mhaberler
Tue Feb 17 11:18:49 2015

---

this is where I'm at in state sharing between tp and using code; it seems unraveling the emcmotstatus and emcmotconfig globals access into what could be HAL pins is the most sensible thing to do; they dont have to, but they could be pins

one would pass such an all-pointers-initialized tp_shared struct to tpInit(), and TP_STRUCT would hold a pointer to it:

*/
typedef struct {
...
tp_shared_t *shared;
...
} TP_STRUCT;

access can be wrapped as static inlines like so:

static inline int get_num_dio(TP_STRUCT *tp) { return *(tp->shared->num_dio); }
static inline int get_num_aio(TP_STRUCT *tp) { return *(tp->shared->num_aio); }

not sure I like it yet.. comments?

// this holds all shared data between using code and the tp
// data items can be pins if so desired,
// in this case the tp_shared struct must live in HAL memory, and
// be allocated by hal_malloc()

struct tp_shared {

// read-only by tp, config items
hal_s32_t   *num_dio;
hal_s32_t   *num_aio;

hal_float_t *arcBlendGapCycles;
hal_s32_t   *arcBlendOptDepth;
hal_bit_t   *arcBlendEnable;
hal_float_t *arcBlendRampFreq;
hal_bit_t   *arcBlendFallbackEnable;
hal_float_t *maxFeedScale;

hal_float_t *acc_limit[3]; // tpGetMachineAccelBounds(PmCartesian * const acc_bound)
hal_float_t *vel_limit[3]; // tpGetMachineVelBounds(PmCartesian * const vel_bound)

hal_bit_t *unlock[EMCMOT_MAX_JOINTS];          // write by tp
hal_bit_t *is_unlocked[EMCMOT_MAX_JOINTS];     // read by tp

// read/write by tp: via emcmotStatus->
hal_float_t *spindleSync;
hal_float_t *current_vel;
hal_float_t *dtg[9]; // an EmcPose
hal_bit_t   *spindle_index_enable;
hal_bit_t   *spindleSync;
hal_float_t *spindle_speed; // was emcmotStatus->spindle.speed

// typedef struct {
hal_float_t *double offset; // rw
hal_float_t *double revs;  // rw
hal_s32_t   *int waiting_for_index;  // rw, a motion ID
hal_s32_t   *int waiting_for_atspeed;  // rw, a motion ID
// } tp_spindle_t;

// write-only by tp: via emcmotStatus->
hal_float_t *requested_vel;
hal_float_t *distance_to_go;
hal_u32_t   *enables_queued;

};

[ArcEye]

Comment by mhaberler
Mon Feb 23 10:08:11 2015

---

joint vel/acc limiting with non-trivkins is an issue in the current planner

I had a chat with Michal this morning and he had an interesting idea which might simplify things significantly. Current ideas were so far focused on joint vel/acc limiting in the motion/tp complex.

But it might be easier to prevent moves which exceed joint limits actually hitting tp/motion. One way this could be done is:

• kinematics are made available to the canon layer (a little API exercise but entirely doable).
• the canon layer (currently cartesian only) becomes kins-aware and then may 'plan' for joint space too, using the above kins API
• the joint vel/acc limiting is thus done on the canon layer, meaning moves coming out of canon will already be joint-limited

as usual feed override gets in the way, but one way to deal with that is to worst-case joint-plan in canon using MAX_FEED_OVERRIDE so moves would still be within joint limits if f/o is cranked up to the maximum

one aspect which gets in the way a bit is the fact that many kins modules use HAL for configuration, meaning any kins must run on a HAL/RT host if left unchanged

[ArcEye]

Comment by cdsteinkuehler
Mon Feb 23 12:47:57 2015

---

I like the idea, and I've been hitting issues with the joint vs. axis
limits recently working on one of my non-Cartesian 3D printers (Wally):

http://conceptforge.org/images/Wally.jpg

...which makes the delta-printer kinematics seem simple by comparison.

Also, since adding this would probably touch the world vs. joint motion
limits, could we PLEASE make the test for allowable movement envelope
a function call instead of a "box"?

Charles Steinkuehler
charles@steinkuehler.net

[ArcEye]

Comment by mhaberler
Thu Feb 26 12:40:42 2015

---

that sounds like a wonderful vtable application to me - a comp which exports a function, gets a pose (or two to test a line), and returns bool

motion could use that function

NB there's another limit check in tastk, needs investigating if both need to be replaced

[ArcEye]

Comment by yishinli
Fri Dec 4 01:38:02 2015

---

Merge LCNC.joint_axes9 with MK.master to MK.joints_axes9.

Current work:

• merge motion parts: emccanon.cc, control.c, command.c. control.c tp.c
• skip conflicts of rtapi/, hal/, kinematics/, configs/

Open issues:

• In LCNC.joint_axes9, those hal files in configs/common/ are moved to lib/hallib, which results a clean configs/sim/ directory without symbolic links. The INI.[HAL]HALFILE seems to be able to access .hal files in hal/hallib directly. Current MK.joint_axes9 can't.
• LCNC.joint_axes9: RTAPI and HAL modifications needs to be reviewed and merged.