2.8.2 Gantry configuration XYZY vs. XYYZ - is it supposed to matter?

More
22 Aug 2021 00:05 #218362 by dokwine
I am doing a fresh install of the 2.8.2 iso on my 5i25/7i76 gantry machine with closed-loop steppers. Everything was running solid under 2.7.x for years and I'm working toward getting back to where I was with 2.7 on 2.8. when I went to setup my vistaCNC pendant I had some conflicts with these lines in the vendor's supplied .hal file:

  # net jog.1.cont-plus  vc-p4s.jog.1.plus  => halui.axis.y.plus  halui.joint.1.plus
  # net jog.1.cont-minus vc-p4s.jog.1.minus => halui.axis.y.minus halui.joint.1.minus
  # net jog.2.cont-plus  vc-p4s.jog.2.plus  => halui.axis.z.plus halui.joint.2.plus
  # net jog.2.cont-mimus vc-p4s.jog.2.minus => halui.axis.z.minus halui.joint.2.minus

This led to a couple questions:
  1. Is there a point to connecting to both the halui axis pin and the halui joint pin for jogging? I understand jogging a single joint on a multi-joint axis for squaring, but then you wouldn't also be jogging the entire axis.
  2. In my case I'm set up in pncconf as XYYZ as the original order in which things were wired on the Mesa in 2.7. pncconf generated a correct-looking [KINS]
    [KINS]
    JOINTS = 4
    KINEMATICS = trivkins coordinates=XYYZ kinstype=BOTH

    and test jogging from axis seems to work fine.

    the .hal lines above would have been a problem though as they assume joint 2 = axis z where on my machine joint 2 is the y axis slave. On a [KINS} XYZY configuration (like the sim gantry example) joint 2 would have remained the z axis and possibly have worked.

    So. I realize this is 3rd-party hal code, but is it possible that elsewhere within LCNC there are assumptions favoring XYZY instead of XYYZ? I haven't found anything in the docs indicating a preference (which doesn't mean I didn't miss it ;)
Thanks,
Ron

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

More
22 Aug 2021 07:02 #218380 by rodw

I am doing a fresh install of the 2.8.2 iso on my 5i25/7i76 gantry machine with closed-loop steppers. Everything was running solid under 2.7.x for years and I'm working toward getting back to where I was with 2.7 on 2.8. when I went to setup my vistaCNC pendant I had some conflicts with these lines in the vendor's supplied .hal file:

  # net jog.1.cont-plus  vc-p4s.jog.1.plus  => halui.axis.y.plus  halui.joint.1.plus
  # net jog.1.cont-minus vc-p4s.jog.1.minus => halui.axis.y.minus halui.joint.1.minus
  # net jog.2.cont-plus  vc-p4s.jog.2.plus  => halui.axis.z.plus halui.joint.2.plus
  # net jog.2.cont-mimus vc-p4s.jog.2.minus => halui.axis.z.minus halui.joint.2.minus

This led to a couple questions:
  1. Is there a point to connecting to both the halui axis pin and the halui joint pin for jogging? I understand jogging a single joint on a multi-joint axis for squaring, but then you wouldn't also be jogging the entire axis.
    • In my case I'm set up in pncconf as XYYZ as the original order in which things were wired on the Mesa in 2.7. pncconf generated a correct-looking [KINS]
      [KINS]
      JOINTS = 4
      KINEMATICS = trivkins coordinates=XYYZ kinstype=BOTH
      and test jogging from axis seems to work fine.

      the .hal lines above would have been a problem though as they assume joint 2 = axis z where on my machine joint 2 is the y axis slave. On a [KINS} XYZY configuration (like the sim gantry example) joint 2 would have remained the z axis and possibly have worked.

      So. I realize this is 3rd-party hal code, but is it possible that elsewhere within LCNC there are assumptions favoring XYZY instead of XYYZ? I haven't found anything in the docs indicating a preference (which doesn't mean I didn't miss it ;)

      Thanks,
      Ron

The order in coordinates determines which joint belongs to which axis so it should be possible to freely move from XYYZ and XYZY etc by changing that value.
But the signals for home and limit switches created by stepconf and pncconf refer to X,Y,Z
Because I never used linuxcnc before we had joint axis, I think this is a carry over from the past. These signal names then become confusing if you do change like above because the second Y in this example will be named for the Z axis.

I would much prefer that these signals were named after the joints eg
joint-0-home not x-home etc
But I lost that argument years ago. To me, it makes the hal file much more readable.

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

More
22 Aug 2021 21:46 #218442 by dokwine
Thanks, Rod. My concern is its not just confusing, but a built-in error.

In my case using XYYZ in pncconf resulted in the correct joints assigned to the correct axis. BUT, when I read down the pncconf-generated .hal under HALUI signals I have
  • "net z-is-homed halui.joint.2.is-homed"
when clearly earlier in the same file I have
  • "#   AXIS Z JOINT 3 ... - with the correct setup for the z axis which is correct
I don't use homing switches and all my axis are homed at the same time so this hasn't been a problem (also I haven't touched pncconf in years), but it makes me wonder where else this assumption (XYZY) may be hiding.
 
Attachments:

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

More
23 Aug 2021 01:18 #218451 by phillc54
That line does need bit of fine tuning but it won't affect your config, it is only a convenience line that is not connected anywhere else.

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

More
23 Aug 2021 11:55 #218498 by rodw
Thats what I was referring to. To me, the first form would make more sense but as I said I lost the argument years ago when 2.8 was first released.
  • "net joint-2-is-homed halui.joint.2.is-homed
  • "net z-is-homed halui.joint.2.is-homed"
The second form is not really consistent with the current architecture.
 
The following user(s) said Thank You: dokwine

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

More
23 Aug 2021 12:25 #218502 by phillc54
Well I don't see that it is much of a problem when you consider that pncconf is really only for trivial kinematics. My take is that from where it appears in the Hal file it is possibly provided as an enable for axis jogging via halui so it does make some sense.

I pushed a change to 2.8 and master that maps the correct joint.
 
The following user(s) said Thank You: dokwine

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

More
23 Aug 2021 20:33 #218546 by rodw
Well, I lost the argument right back when V2.8 was the master branch and the shiny new joint axis code was released. So I have no hope winning it now!
If pncconf and stepconf referred to joints it would follow all the ini file format etc.  Then all that is required is that the user entered the KINS data including a string for coordinates = XYZY, XYYX, YYXZ or whatever he wanted and pncconf should be able to support any kinematics and axis to joint mapping he wanted.

PNCCONF's restriction to trivial kinematics really stems back to not properly updating it for the move to independent joints/axes when I lost the argument.

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

More
24 Aug 2021 00:38 #218566 by phillc54

PNCCONF's restriction to trivial kinematics really stems back to not properly updating it for the move to independent joints/axes when I lost the argument.

I don't think that is the case, I think it is more that no-one has the time it would take to achieve, it would be a massive undertaking.
The following user(s) said Thank You: tommylight

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

More
24 Aug 2021 10:05 #218606 by rodw

I don't think that is the case, I think it is more that no-one has the time it would take to achieve, it would be a massive undertaking.

So was the joint axis work. It was released about 5 years ago.... I found it frustrating then that there were a number of bugs in the GUI's because the changes were not fully integrated but pncconf was not something I looked at then cos it did not support the 7i76e.

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

More
24 Aug 2021 10:45 - 24 Aug 2021 11:01 #218612 by phillc54
Well if you are so concerned about it now then instead of spending time complaining you could spend some time changing it to your requirements. I don't think anyone else is going to.
Last edit: 24 Aug 2021 11:01 by phillc54.

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

Time to create page: 0.104 seconds
Powered by Kunena Forum