# Linking two gantry joints with homing switches so it unracks on home

22 May 2022 12:15 #243552

What  I mean, if you start with -2, then isn't the sequence -2,-1,0,1,2....

Nope, that will not work.
The sequence is 0,1,2,3.... but any of those has a - means it is tandem and has another joint attached to it.
So, 0,1,-2,3
or 0,-1,2,3
or 0,1,2,-3
are all correct.
Rod's logic is right, but in this case the - is used to mark a tandem axis.

22 May 2022 12:18 #243553

This is the confusion I see. -2 is illegal by my read.

[/quote]
It is not, all my machines have -2 for Y axis joints, the gantry is still inside the shop!

22 May 2022 13:44 #243558

What  I mean, if you start with -2, then isn't the sequence -2,-1,0,1,2....

I think the part that has gotten skimmed over is: The absolute value of sequence numbers must increment by one — skipping sequence numbers is not supported.

so on one config of mine with YYXZ, I have HOME_SEQUENCE of -1,-1,1,0 which has worked for 5 years and complies with the docs..

This would work, because you didn't skip any numbers in the absolute value of the home_sequence count. Z would home first, and then X and Y would home at the same time with a synchronized final movement.

22 May 2022 19:05 - 22 May 2022 19:06 #243568 by rodw
OK, homing.c works with absolute values for home sequences but this statement is incorrect.

This would work, because you didn't skip any numbers in the absolute value of the home_sequence count. Z would home first, and then X and Y would home at the same time with a synchronized final movement.

Z homes, X homes, then Y the synchronised axis homes last.
I am guessing pncconf uses -2 in the mistaken belief that it is required for the gantry to home last.
I do find this very confusing.
Its interesting that the behaviour and/or documents have changed over time since I was arguably the first to adopt the new joint axes features on a gantry machine when released into master branch back when v 2.8 was master branch.

But we've been sidetracked. Why must a synchronised axis not support jogging before homing AND respect the synchronised HOME_OFFSET? eg you jog Y1 nad Y2 moves with it. I am struggling to think of a use case where this would be dangerous.... Maybe there is room for another change here.
[/quote]
Last edit: 22 May 2022 19:06 by rodw.

22 May 2022 19:26 #243572
Joint mode = means controlling joints, and as such Y1 and Y2 are not the same thing, each has it's own ... everything.
As for understanding, i am not understanding why is this subject still going on, i am sure it can be done in hal so that they move together, but still do not know why ....

22 May 2022 20:31 - 22 May 2022 20:35 #243575

OK, homing.c works with absolute values for home sequences but this statement is incorrect.

This would work, because you didn't skip any numbers in the absolute value of the home_sequence count. Z would home first, and then X and Y would home at the same time with a synchronized final movement.

Z homes, X homes, then Y the synchronised axis homes last.

What I wrote is absolutely correct, and how it works, and follows the both the 2.8.2 and 2.9 docs. Perhaps you are misremembering your setup, or you are not up to date.

Video to support (joint 3 is Z, joint 0 is X, and joints 1 and 2 make up tandem Y). Z homes, then X and Y home together, and they all wait to make the final move.
Warning: Spoiler!

From the docs:

Negative HOME_SEQUENCE values indicate that joints in the sequence should synchronize the final move to [JOINT_n]HOME by waiting until all joints in the sequence are ready. If any joint has a negative HOME_SEQUENCE value, then all joints with the same absolute value (positive or negative) of the HOME_SEQUENCE item value will synchronize the final move.

A negative HOME_SEQUENCE also applies to commands to home a single joint. If the HOME_SEQUENCE value is negative, all joints having the same absolute value of that HOME_SEQUENCE will be homed together with a synchronized final move. If the HOME_SEQUENCE value is zero or positive, a command to home the joint will home only the specified joint.

I am guessing pncconf uses -2 in the mistaken belief that it is required for the gantry to home last.
I do find this very confusing.

This is user configurable in pncconf, it will make the sequence whatever you enter (there is a scenario where it wont, but we wont got there now). Save for if it's a tandem axis, it will add a negative sign in front of the sequence number.
Last edit: 22 May 2022 20:35 by snowgoer540.

25 May 2022 00:55 - 25 May 2022 01:54 #243738 by dannym
Ok, testing found a prob- if you use the mpg jogwheel and press the axis go-home button that calls G0 Y0, it throws a following error.  It was pretty easy to hit this prob.

Now if it's already running gcode, the jogwheel is locked out and there's no error.  But if you're turning the jogwheel and press anything that calls a gcode command or actually start a gcode file then you always get the following error

2.7 didn't have any prob.  Apparently 2.8 has a prob with jogging and  an interpreter command at the same time.  Granted, not much reason to hit a gcode command while moving, but for "go to axis home" it's not too unusual and Following Error is a REALLY ungraceful response.

My mpg hal does have a low pass filter so the motion is not jerky.  That does mean it will have some pending movement for a moment after stopping the wheel, so gating off the mpg jog counts when executing a command won't fix it.

Any ideas?
Last edit: 25 May 2022 01:54 by dannym.

25 May 2022 06:39 #243761 by dannym
Also, gotta note- I discovered the hard way that the gantry can get past one of the X-limit switches if you jog it all the way to the stop.

Never noticed in 2.7 because you can move the gantry before homing.  2.8 not being able to do that made the machine unrecoverable.  The homing cycle won't work because it went past the switch and will "home" forever by driving into the stops looking for the switch in the wrong direction.  It needs to back off a small amount to trigger the homing switch before it can do the homing cycle, but you can't move it with 2.8.

There IS  reason to do coordinated gantry motion prior to homing, it turns out.

25 May 2022 09:04 #243767 by rodw
note that 2.8 and on expect that the home switch stays triggered all the way to the limit of travel. That way it knows from the home switch state at the start of homing which way it needs to move. Get it wrong and its not pretty!