Weird homing behavior. Y+Y2 out of sync

rodw wrote:

Clive S wrote:

HOME_SEQUENCE = -2 ( this is fine for both Y joints)
 
That does not agree with the docs which state:
The initial HOME_SEQUENCE number may be 0, 1 (or -1). The absolute value of sequence numbers must increment by one — skipping sequence numbers is not supported. If a sequence number is omitted, HOME ALL homing will stop upon completion of the last valid sequence number.
Ref:  linuxcnc.org/docs/devel/html/config/ini-...tml#_homing_sequence

I don't see where he is skipping numbers

He has in the ini file :-
HOME_SEQUENCE Z = 0 . X = 1 . Y1 and Y2 = -2

They do have the same HOME_FINAL_VELOCITY. In my understanding 0 = max velocity setting? And both joints were set to 25000mm/min if I remember correctly.
Here's a video Tommy

Rod, I've tried many different combinations for the homing sequence - always the same result...

That looks perfectly normal.
The only possible issue might be miss wired switches, although i doubt it, so rake the gantry a bit on one side by hand and then home while watching from the side.
Otherwise, all is good, you have the final velocity set to maximum or 0 so after latching it flies to the final position, so a small difference during latching is magnified by the speed and the short distance it takes to get to final position.
Mine do that daily and i have some offset (5mm difference between them), but i have HOME_FINAL_VELOCITY at 30 so it goes slower and i enjoy watching them do their dance !

tommylight wrote:

That looks perfectly normal.

I am not sure that it does. It seems that the final moves to home happen separately. 

It might be more obvious if the HOME_POSITION was further from the end. But I am hesitant to suggest that in case there really is a problem and this pulls the gantry apart. 

Can you use Halscope to log the velocity of each Y joint and also the joint.N.home-state ?
(I suggest adding joint.0.is-homed as the halscope trigger) 
 

andypugh wrote:

I am not sure that it does.

I agree, I slowed the video way down and they are happening separately.

I don't really follow your home/limit switch combination. It looks to me like you have:
home-y (input 001)
home-y2 (input 000)
home-x (input 002)
home-z (input 003)

The bit I'm confused on is:
max-x (input 004)
min-y (input 005)

What you are after can be achieved with 4 switches. If your axis travels lengths (MIN and MAX LIMIT) are properly input, unless you lose steps, you wont run past the max or the min. LinuxCNC sets and obeys these soft limits automatically.

Try using PNCCONF to set up the following:
input 000 -> Y2 Minimum Limit + Home
input 001 -> Y Minimum Limit + Home
input 002 -> X Minimum Limit + Home
input 003 -> Z Minimum Limit + Home (I think this is correct, but if it goes the wrong way then use Z Maximum Limit + Home)

I haven't seen anything but your hal and ini files, but I cant see an immediate reason why you need to use gpio.004 and gpio.005 as you did previously.

Also, your HOME_SEQUENCE (Z = 0, X = 1, Y and Y2 = -2) is correct, you can choose to do tandem axis last (-2 in your case).

For HOME_SEQUENCE, you are also not required to start at 0, and you can use the - sign on axes that are not tandem as well to designate that you don't want to be able to jog the axis until it is homed. In this example, you have to start the count at 1, because "-0" doesn't work. I choose to do this on my table so it cannot be jogged at all prior to homing (prevents crashes into hard stops, etc.). This is not well (maybe not at all) documented, but it does work fine.

My HOME_SEQUENCE entries to achieve this are as follows:
Z = -1
X = -2
Y and Y2 = -3