Beginners homing woes

Hey there

I'm still on the bench testing my Remora NVEM setup before putting the servos and switches on the XYYZ machine.

Servos and Switches seem to work technically speaking. Servos move when jogging and switches go high/positive on contact with metal.
I for now don't plan to use limit switches but may be later.

Thus my configuration should be straight forward.. i thought. But I can't get homing to work. Whenever I start the procedure via UI (AXIS) it either does nothing or seems to "jump" straight to home. I'm sure the problem is within the configuration, but I just cant seem to figure it out, as I dont get any errors. Expected behavior would be servo moving and me triggering the home switch.

Thanks a lot for any hints/pointers,
Alessandro

The first problems I see are with your joint/axis assignments and your home sequence numbers.

In your [TRAJ] section of your ini file you have
COORDINATES = X Y Y Z

This will assign joint 0 to the X axis, joints 1 and 2 to the Y, and joint 3 to the Z.
That is perfectly acceptable, but it seems to get confused below that in the Joint and Axis sections of the ini file.

To configure the Y axis to use joints 1 and 3 your would need:
COORDINATES = X Y Z Y

First which joints do you actually have connected to which axis?

2nd the joints that are assigned to the Y axis must be given matching negative numbers for their HOME_SEQUENCE = setting.

If you are wanting the Y axis to home 1st, don't use HOME_SEQUENCE = 0. It is not required that zero is used in the home sequence. For a duel joint gantry axis, use HOME_SEQUENCE = -1 for both of the joints assigned to the axis(or -2, or -3...)

Usually the Z axis is homed first in most configurations to make sure that the spindle is out of the way for the other axis to home later.

If you are using joint 3 as the Z axis I would suggest moving the [AXIS_Z] section down just above the [JOINT_3] section in your ini file.

in your hal file it looks like you have Z connected to joint 2. And I don't see a home switch connection for joint3 (both of the Y axis joints must have seperate home switch inputs from each other.)

Thanks Todd for looking over my setup.

Your laying out of the not-so-clear configuration led me to move things where they belong. The Z-Axis Configuration is driven by Joint 3. But since I only added the second Y later, it came after the Z's definition.
When I changed the ordering I realised that my homeing Order wasn't correct either. Which led to the situation that LinuxCNC would try to home an axis that i hadn't attached yet (Z's Joint). Which then in turn would lead to a situation where Y and X would never home and me waiting forever. Having now fixed the priorities, axis do home as they should. Thanks for pushing me to it!

That said for the Gantry: does it make sense to use keep the trivial trajectory setup or would I rather use one of the available gantry components to manage Y? I havent really found pros and cons online. Both side of the gantry should are fixed by leadscrews so theres little to no tilting possible.

Thanks again,
Alessandro

Any Gantry components have been made onsolete 2 versions ago with v2.8. Please read homing configuration as the gantry set up is all to do with homing.

No, you should just leave the Kins setting as Trivkins. As Rod was trying to say, the Trivkins machine model was modified to handle slaved joint gantries in version 2.8, as well as handle arbitrary joint to axis assignments. There is no need to to try to use another kins model.

Now a history lesson. (Stop reading if you don't care.) Previous to v2.8 the Trivkins machine model was truly simple. Just assigning each joint 0-8 to each axis x,y,z,a,b,c,u,v,w respectively. Such that if you needed a config that used axis X,Y,Z, and W. you had to set up and configure dummy joints and axis for the unused A,B,C,U,V axis. You could hide the unused axis in the user interface configuration so they were not seen, but they were still there under the skin. There was also no means for attaching multiple joints to an axis or to square a gantry. That necessitated the gantry kins config, it was a bit of a kludge and caused some minor confusion of joints and axis within Linuxcnc most noticeable with some user interfaces. With the merger of the Joints/Axis development branch into 2.8 (while 2.8 was in development as Master) the last version Gangrykins eventually became/was developed into the current version of Trivkins. Previous to Joints/Axis, the defining/separation of a joint and an axis, was not always clear or separated in the Linuxcnc code. This wasn't a big deal for trivial machines or even much of a problem for a gantry, but it could complicate setting up and running non trivial machines where the movement of a joint did not identically match the movement of an axis. Hence the push to clearly separate in the Linuxcnc codebase the difference between a joint and an axis.

Hey there, sorry for the late response.
I wanted to get back whenever the machine and the servos are in their places and actually drive something.
Thanks again for your help and explanations. Understanding the historical context can be very helpful especially when looking for example configuration that may be 2.7 and earlier.

In any case, while I tested all axis back then without problems I think I never tested driving two joints (servos) on the same axis. I use TRIVKINS X Y Y Z. Where

Now with everything on the machine I can drive joint 1 (first Y servo) just fine. Joint two doesn't do a thing. Looking at the HAL output I can see that Joint2 (doesn't get any commands. I briefly wired that servo the Z-Axis just to test the wiring and it's moving without a problem. Is there something I should be checking beyond the TRIVKINS portion?

pastebin.com/3gND7BUk

Is what I have now.


Also if we're at it, would such a setup benefit from two homing sensors on the Y axis? The gantry is rigid.


Thanks again,
Alessandro

For a gantry machine you must have homing sensors on both sides of the gantry.
for an XYYZ machine, start with a HOME_SEQUENCE of 0, -1, -1, 2  for each joint in order
Ref: linuxcnc.org/docs/stable/html/config/ini...l#sec:homing-section

Is this that a software requirement and/or is there merit in hardware wise as well for separate sensors?

I reconfigured both Y joints as -1 on the HOME_SEQUENCE and now LinuxCNC requires me to home first before jogging. Is there a way to test/jog Joint 2 independently like I did with Joint 1 before?