Making some axes independent of the motion controller

And here's the complicated MCode I wrote to control that axis:

Well, now I'm really confused.

I was using a damaged 7i76e board that only had 1 working Stepgen output for my testing. I had gotten my limit3 modified .hal file working fine on it and I was hopeful that everything was going to be straightforward. Some replacement chips arrived and I gave the board to my coworker to do some rework. His replacements didn't work (maybe other chips were fried?) but the last Stepgen was still functioning. Except now I'm finding that I get a Following Error during the middle of my homing cycle. I'm perplexed as to why I'm suddenly more prone to a Following Error when the change should've been downstream of everything affected. Unless the output buffer chips affect the feedback? Frustrating...

False Alarm. I had cleaned up my .hal file a bit and had a typo that was blowing up my pid feedback. Gonna update the .hal snippet I posted.

That's awesome! I hope other people find that feature useful as well.

My kludge version utilizing both the motion controller and limit3 seems to be working on the bench, although I had to edit the .hal file again to fix the ordering of the servo-thread to correct an f-error offset.

In a few days I'll be testing this on the full robot. We just have to change how we're generating the g-code a bit.

What I'd love to implement is a system where X,Y,Z
stay in lock-step and those values go to the motion planner.
However, all the other elements can be independent ...

I've made a branch implementing a method for adding 'extra'
joints. The 'extra' joints use the standard LinuxCNC homing
mechanism but are not included in kinematics calculations.

After homing, the 'extra' joints can be managed by an
independent motion planner (like limit3). The planner
can be accessed directly from hal. Access can include
M commands issued by a gcode program or MDI.

Ref: github.com/LinuxCNC/linuxcnc/commits/dgarr/extrajoints

The branch includes demo sim configs that illustrate the
pre-home and post-home behavior and the additional hal logic
required. A simple M command and widgets to update/display
hal settings are included.

The branch can be built from source for run-in-place (RIP)
usage or installed from a buildbot scratch deb. To install a
buildbot deb, see: buildbot.linuxcnc.org

Notes:
1) Buildbot debs for scratch branches are not kept indefinitely.
2) The branch is force-pushed when updating or rebasing to
the master branch.

I've replaced the branch dgarr/extrajoints with a new branch:
dgarr/motion_extrajoints

This branch supports 'extra' joints with any kinematics
module and simplifies usage.

Ref: github.com/LinuxCNC/linuxcnc/commits/dgarr/motion_extrajoints

The branch includes a commit that increases the total number
of joints available (kinematic joints plus extra joints) to 16.

thanks to Andy for suggestions

Does the increase in total joints allow for the possibility
of kinematics with 9 coordinates but > 9 joints?

Above provides 9 joints that support the kinematics for
the 9 xyzabcuvw coordinates and 7 'extra' joints for independent
motion planning (a total of 16 joints).

If one needed two motors for a coordinate (gantry-like: xxyzabcuvw),
there would be at most 6 'extra' joints.

Example axis gui support for extra joint jogging and dro for 16 joints: