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

Please Log in or Create an account to join the conversation.

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...

Please Log in or Create an account to join the conversation.

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.

Please Log in or Create an account to join the conversation.

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

Please Log in or Create an account to join the conversation.

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.

Please Log in or Create an account to join the conversation.

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

Please Log in or Create an account to join the conversation.

More
23 Jan 2019 01:16 #124641 by dgarrett
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

Please Log in or Create an account to join the conversation.

More
23 Jan 2019 10:36 #124654 by andypugh
Does the increase in total joints allow for the possibility of kinematics with 9 coordinates but > 9 joints?

I can't think of many applications, but there was a "snake" actuator suggested some time ago.
www.ocrobotics.com/technology-/series-ii-x125-system/

Please Log in or Create an account to join the conversation.

More
23 Jan 2019 14:59 #124670 by dgarrett

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.

Please Log in or Create an account to join the conversation.

More
23 Jan 2019 16:57 #124675 by dgarrett
Example axis gui support for extra joint jogging and dro for 16 joints:
Attachments:
The following user(s) said Thank You: andypugh, tommylight

Please Log in or Create an account to join the conversation.

Time to create page: 0.132 seconds
Powered by Kunena Forum