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

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

dokwine wrote:

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.

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.
 

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.

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.
 

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.
 

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.

rodw wrote:

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.

phillc54 wrote:

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.

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.