Making some axes independent of the motion controller
#!/bin/bash # change the setpoint of the limit3.1 motion planner (Tipper) halcmd setp limit3.b.in $1 exit 0
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...
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.
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
1) Buildbot debs for scratch branches are not kept indefinitely.
2) The branch is force-pushed when updating or rebasing to
the master branch.
This branch supports 'extra' joints with any kinematics
module and simplifies usage.
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
I can't think of many applications, but there was a "snake" actuator suggested some time ago.
Does the increase in total joints allow for the possibility
of kinematics with 9 coordinates but > 9 joints?
... [KINS] JOINTS = 16 KINEMATICS = trivkins kinstype=both coordinates=xyzabcuvw ... [EMCMOT] EMCMOT = motmod num_extrajoints=7 ...
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.