Discussion:
Question on comment in axis script
(too old to reply)
Kurt Jacobson
2017-04-08 18:18:28 UTC
Permalink
Raw Message
Hello all,

I have been trying to understand how the axis UI works and came across this
comment starting on line 3333 of bin/axis in a fresh pull of 2.8 pre:

duplicate_coord_letters = ""
for i in range(len(trajcoordinates)):
if trajcoordinates[i] == " ": continue
if trajcoordinates.count(trajcoordinates[i]) > 1:
duplicate_coord_letters = duplicate_coord_letters +
trajcoordinates[i]
if duplicate_coord_letters != "":
# Can occur, for instance, with trivkins with kinsmodule=both).
# In such kins, the value for a duplicated axis letter will equal the
# value of the highest numbered joint.
# Movements on axis gui display in joint mode (after homing) may be
unexpected,
# e.g., moving a joint that is not the highest number will not
affect the
# corresponding 'identity' coordinate.
print ("Warning: Forward kinematics must handle duplicate coordinate
letters:%s"%
duplicate_coord_letters)


I am confused by the sentence "In such kins, the value for a duplicated
axis letter will equal the value of the highest numbered joint."

What does this mean?

I though that for an XYYZ config the axis:joint relation should be {X:0,
Y0:1, Y1:2, Z:3} so the value for a duplicated axis letter is actually
unlikely to equal the value of the highest numbered joint. Or is that not
even what the comment is referring to?

Sorry for bothering you all again!

Thanks,

Kurt
Sebastian Kuzminsky
2017-04-08 18:58:34 UTC
Permalink
Raw Message
Post by Kurt Jacobson
Hello all,
I have been trying to understand how the axis UI works and came across this
duplicate_coord_letters = ""
if trajcoordinates[i] == " ": continue
duplicate_coord_letters = duplicate_coord_letters +
trajcoordinates[i]
# Can occur, for instance, with trivkins with kinsmodule=both).
# In such kins, the value for a duplicated axis letter will equal the
# value of the highest numbered joint.
# Movements on axis gui display in joint mode (after homing) may be
unexpected,
# e.g., moving a joint that is not the highest number will not
affect the
# corresponding 'identity' coordinate.
print ("Warning: Forward kinematics must handle duplicate coordinate
letters:%s"%
duplicate_coord_letters)
I am confused by the sentence "In such kins, the value for a duplicated
axis letter will equal the value of the highest numbered joint."
What does this mean?
I though that for an XYYZ config the axis:joint relation should be {X:0,
Y0:1, Y1:2, Z:3} so the value for a duplicated axis letter is actually
unlikely to equal the value of the highest numbered joint. Or is that not
even what the comment is referring to?
The comment that you pointed out seems maybe a little out of place
there, but it's highlighting a complication that arises from Axis'
attempt to hide the difference between joints and axes from the user.

Axis keeps a mapping of axes to joints (this works ok on trivkins
machines and not at all on non-trivkins machines). But what should
happen on trivkins machines like gantries, which have duplicated axis
letters? I'd interpret that comment as saying that when an axis is
handled by multiple joints, the axis maps to the highest-numbered of
those joints. So i'd expect the mappings in your example to be {X:0,
Y:2, Z:3}. Remember, LinuxCNC only knows X, Y, and Z (and A, B, C, U,
V, and W), it doesn't know Y1 and Y2.

But then i went and read the code, and now i'm confused.

Take a look at the jnum_for_aletter() function, which takes an axis
letter like "X" or "Y", and returns an integer indicating the joint that
moves that axis. On trivkins machines it returns the index of the
*first* occurrence of the axis letter, which is opposite of what the
comment says. But then that function is not called any more (the
calling code was removed), so maybe it doesn't matter and the comment
and the dead code should both be removed.

The function used to be used by the home & limit indicators on the DRO
tab, but they were removed during the massive Joints/Axes cleanup effort.
--
Sebastian Kuzminsky
Kurt Jacobson
2017-04-08 19:38:10 UTC
Permalink
Raw Message
Post by Sebastian Kuzminsky
I'd interpret that comment as saying that when an axis is
handled by multiple joints, the axis maps to the highest-numbered of
those joints.
Interpreted that way it makes a whole lot more sense, as long as you don't
read the surrounding code...

Take a look at the jnum_for_aletter() function, which takes an axis
Post by Sebastian Kuzminsky
letter like "X" or "Y", and returns an integer indicating the joint that
moves that axis.
Thanks for pointing out that that function is not called anywhere, I had
not noticed that.

The function used to be used by the home & limit indicators on the DRO

tab, but they were removed during the massive Joints/Axes cleanup effort.
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
reading.

Thanks much Sebastian, you have cleared a lot of things up.

Kurt
Post by Sebastian Kuzminsky
Post by Kurt Jacobson
Hello all,
I have been trying to understand how the axis UI works and came across
this
Post by Kurt Jacobson
duplicate_coord_letters = ""
if trajcoordinates[i] == " ": continue
duplicate_coord_letters = duplicate_coord_letters +
trajcoordinates[i]
# Can occur, for instance, with trivkins with kinsmodule=both).
# In such kins, the value for a duplicated axis letter will equal the
# value of the highest numbered joint.
# Movements on axis gui display in joint mode (after homing) may be
unexpected,
# e.g., moving a joint that is not the highest number will not
affect the
# corresponding 'identity' coordinate.
print ("Warning: Forward kinematics must handle duplicate coordinate
letters:%s"%
duplicate_coord_letters)
I am confused by the sentence "In such kins, the value for a duplicated
axis letter will equal the value of the highest numbered joint."
What does this mean?
I though that for an XYYZ config the axis:joint relation should be {X:0,
Y0:1, Y1:2, Z:3} so the value for a duplicated axis letter is actually
unlikely to equal the value of the highest numbered joint. Or is that not
even what the comment is referring to?
The comment that you pointed out seems maybe a little out of place
there, but it's highlighting a complication that arises from Axis'
attempt to hide the difference between joints and axes from the user.
Axis keeps a mapping of axes to joints (this works ok on trivkins
machines and not at all on non-trivkins machines). But what should
happen on trivkins machines like gantries, which have duplicated axis
letters? I'd interpret that comment as saying that when an axis is
handled by multiple joints, the axis maps to the highest-numbered of
those joints. So i'd expect the mappings in your example to be {X:0,
Y:2, Z:3}. Remember, LinuxCNC only knows X, Y, and Z (and A, B, C, U,
V, and W), it doesn't know Y1 and Y2.
But then i went and read the code, and now i'm confused.
Take a look at the jnum_for_aletter() function, which takes an axis
letter like "X" or "Y", and returns an integer indicating the joint that
moves that axis. On trivkins machines it returns the index of the
*first* occurrence of the axis letter, which is opposite of what the
comment says. But then that function is not called any more (the
calling code was removed), so maybe it doesn't matter and the comment
and the dead code should both be removed.
The function used to be used by the home & limit indicators on the DRO
tab, but they were removed during the massive Joints/Axes cleanup effort.
--
Sebastian Kuzminsky
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/emc-developers
Sebastian Kuzminsky
2017-04-08 21:01:19 UTC
Permalink
Raw Message
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
reading.
If i recall correctly, we decided that after the big Joints/Axes
cleanup, homing should be handled this way:

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
mode: http://linuxcnc.org/docs/devel/html/code/code-notes.html#_free

If the whole machine is homed, Motion may be in any of the three modes
(Free, Teleop, and Coord):
http://linuxcnc.org/docs/devel/html/code/code-notes.html#_free
http://linuxcnc.org/docs/devel/html/code/code-notes.html#_teleop
http://linuxcnc.org/docs/devel/html/code/code-notes.html#_coord


Dewey, does my hazy memory match all the awesome work you did here?


Now, what this means for GUIs I think is this:

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
joints are not shown. Homing indicators in this state are superfluous:
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.
--
Sebastian Kuzminsky
Kurt Jacobson
2017-04-09 04:51:35 UTC
Permalink
Raw Message
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.

Dewey just commited and removed the dead jnum_for_aletter() function and
greatly improved the comment that confused me. Thanks Dewey, even I can
understand the comment now!

Also I was able to get my UI to indicate homing correctly for trivkins and
I can now run a gantry which I was never able to do before. Still need to
do some work to get the indicators to be correct for a gantry, but that
should not be too hard. Just need to change to referencing the indicators
by joint number instead of axis index, but that might be easier said than
done.

Thanks again,

Kurt
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
reading.
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
mode: http://linuxcnc.org/docs/devel/html/code/code-notes.html#_free
If the whole machine is homed, Motion may be in any of the three modes
http://linuxcnc.org/docs/devel/html/code/code-notes.html#_free
http://linuxcnc.org/docs/devel/html/code/code-notes.html#_teleop
http://linuxcnc.org/docs/devel/html/code/code-notes.html#_coord
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.
--
Sebastian Kuzminsky
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/emc-developers
Loading...