Sebastian, that is fantastic information, I think I am starting to
understand JA homing now. Thanks for taking the time to explain it so
thoughtful, I will be squirreling this away for future reference for sure.
greatly improved the comment that confused me. Thanks Dewey, even I can
I can now run a gantry which I was never able to do before. Still need to
should not be too hard. Just need to change to referencing the indicators
Post by Sebastian Kuzminsky Post by Kurt Jacobson
Thats interesting. I am currently trying to overhaul my custom UI to
support joins/axes. I have got most of it converted by am having trouble
with the homing indicators, thats why I was looking at that code, but it
turns out that the code is not used any longer. I better do some more
If i recall correctly, we decided that after the big Joints/Axes
Joints can be homed or unhomed.
You can ask LinuxCNC to home an unhomed joint, or to home all joints
together (according to their [JOINT_*]HOME_SEQUENCE).
If any joint is unhomed, the whole machine is considered unhomed. If
all joints are homed, the whole machine is considered homed.
If the whole machine is unhomed, the Motion controller must be in Free
If the whole machine is homed, Motion may be in any of the three modes
Dewey, does my hazy memory match all the awesome work you did here?
First, let's sort all possible machines into two categories: the ones
with "trivial kinematics" (sometimes called "trivkins") and the ones
with "nontrivial kinematics" ("non-trivkins"). On trivkins machines the
motion of travel of each joint corresponds to movement along an axis
(think of a mill or a lathe), on non-trivkins machines the
correspondence between joint movement and axis movement is more
complicated (think of a robot arm or a delta printer).
Now lets sort the trivkins machines into two categories: the ones where
there's a "1 joint equals 1 axis" mapping and the ones where the mapping
is more complicated (think of a dual-motor gantry).
All three of these categories are represented the same way inside
LinuxCNC. Each one has a list of joints, homed or not, and a list of
axes, and so on.
If a GUI wants to work with all three kinds of machines, it could just
treat everything as the hardest-to-handle kind, the non-trivkins machine.
When the machine first starts, it's in E-stop, the machine is Off,
Motion is in Free mode, and all joints are unhomed.
The GUI at this point can display a Free-mode, joint-oriented view of
the machine where the joints are shown and the axes are not, and
per-joint homing indicators show the joints are all unhomed. The
operator can jog the joints individually (not what you want on a
gantry!) and request homing.
When the final joint finishes homing, Motion automatically switches to
Teleop mode. The GUI at this point can switch to a Teleop-mode,
axis-oriented view of the machine where the axes are shown and the
the machine *must* be all homed to even be here, by design.
This is pretty much what the Axis GUI does on non-trivkins machines, and
on trivkins machines that do not have a 1:1 mapping between joints and
axes (like gantry machines).
On 1:1-mapped trivkins machines Axis takes a different approach, and
does not make such a big deal of Free mode at the beginning. Since on
1:1 trivkins machines there *is* a simple mapping between joints and
axes, Axis just pretends in Free mode that the joints actually *are* the
axes they're mapped to, and make it look that way to the user.
Well that got long winded. Hope it helps explain homing indicators
somewhat in the brave new Joints/Axes world we live in now.
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Emc-developers mailing list