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


On Sat, Apr 8, 2017 at 2:58 PM, Sebastian Kuzminsky <s...@highlab.com> wrote:

> On 04/08/2017 12:18 PM, Kurt Jacobson wrote:
> > 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?
>
> 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
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
------------------------------------------------------------------------------
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
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to