Making some axes independent of the motion controller

More
09 Jan 2019 00:02 #123806 by cogzoid
And here's the complicated MCode I wrote to control that axis:
#!/bin/bash
# change the setpoint of the limit3.1 motion planner (Tipper)
halcmd setp limit3.b.in $1
exit 0
More
11 Jan 2019 18:49 #123985 by cogzoid
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...
More
11 Jan 2019 19:56 #123988 by cogzoid
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.
More
11 Jan 2019 23:34 #123998 by andypugh
I have made a start on a single axis motion planner HAL component. (Limit4 + built in homing) but it isn’t going to get finished in less than a week at best.
The following user(s) said Thank You: chimeno, tommylight, Grotius, cogzoid
More
14 Jan 2019 19:34 #124179 by cogzoid
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.
More
15 Jan 2019 03:01 - 18 Jan 2019 23:49 #124219 by dgarrett

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.
Last edit: 18 Jan 2019 23:49 by dgarrett. Reason: branch name superseded
The following user(s) said Thank You: cogzoid
Time to create page: 0.091 seconds
Powered by Kunena Forum