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

The only reason you could possibly want to jog the gantry independently before homing is to square the gantry.
This is no longer necessary because this is achieved in software when homed.
If your home switches are not  aligned perfectly, you just need to adjust the HOME_OFFSET for each joint in your ini file accordingly.
eg in my case I have gantry HOME_OFFSETS of 45mm and 43mm to adjust by 2mm.

Your new workflow will become:
power machine on
Press power on in the GUI
Press home all
Make something!
Put up a sign and your users will adapt to the simplified process I am sure.

 

I can think of several reasons you might need to jog before homing, Here is an example.

Lets say you are side drilling something using an aggregate tool and the power goes out. Once you finally get your machine powered up again, you must manually jog the tool out of the material before you can begin the homing sequence because the homing sequence would crash the machine.

Hmm I don't understand why this is strange.  Sometimes we need to fix things before homing- for one, when people leave the gantry over at the far side.  Homing is pretty slow to get it back.

But the bigger problem is not just that you can't do that, but that you can press arrow keys like you always did and rack the axis pretty hard, maybe enough to damage the axis, or at least jam it so hard it may have trouble unracking.  I can see people doing that over and over.  I know you just shouldn't do that, but again, big user base here I'm not in regular contact with.  This one isn't me being resistant to change, it's what I can reasonably foresee is going to happen with all these other casual users.  I'd put up a note but that has had limited success in the past.

Can the keys for it just be disabled entirely while in the unhomed state?

What about my XHC?  Would this work? (will try tomorrow).  The jogwheel only has one lowpass filter that goes to every axis and joint and just relies on one joint/axis being enabled or not by the axis selector knob and the fact that it's in joint mode or axis mode.
If this works, but we can't get the keyboard to drive joint.4 along with joint.0 when unhomed, is there a way to disable the arrow keys when unhomed so it won't rack the gantry but still be able to jog the gantry with the xhc?net jog-x axis.x.jog-enable joint.0.jog-enable joint.4.jog-enable <= xhc-hb04.jog.enable-x #Lowpass Filtering for mpg
addf mult2Lowpass servo-thread
setp ilowpass.0.scale 1000
setp ilowpass.0.gain 0.01
net jog-counts_in xhc-hb04.jog.counts => ilowpass.0.in
net jog-counts_out ilowpass.0.out => joint.0.jog-counts joint.4.jog-counts axis.x.jog-counts joint.1.jog-counts axis.y.jog-counts joint.2.jog-counts axis.z.jog-counts joint.3.jog-counts axis.a.jog-counts halui.feed-override.counts halui.spindle.0.override.counts

to prevent jogging before homing change 

KINEMATICS = trivkins coordinates=XXYZA kinstype=BOTH
to:
KINEMATICS = trivkins coordinates=XXYZA

Yeah we'd like to have at least YZA jog keys available prior to homing, except an arrow key that racks the gantry isn't acceptable. If the XHC works as intended and will just fan out the X-jog to joint.0 and joint.4, we have what we need- except that keyboard arrow that racks the gantry is still active and that's the unacceptable part.  It wouldn't be so bad if it was an unfamiliar key that drives a gantry motor separately.  But the arrow keys are intuitive and people are going to go for them.

Disabling the left/right jog keys in joint mode is acceptable. Disabling all XYZA jog keys in joint mode (they still need to work in axis mode) in favor of the XHC jogging is acceptable.

I see no scenario where we need to drive joints X1 and X2 independently.  Unrack homing is automatic now, and no one was ever trained to use joint mode to drive X1 independently to square it with X2.  

Like I say, it's not just about me. Large open membership user base who come in any time of day unsupervised- which is great that LinuxCNC has been good for this! I could get the labelmaker and print out something to stick to the monitor, but in my experience some people won't even see that or won't "get" what this very short sentence means.

Hmm, I'm rechecking the manual- again, machine is at the shop and being used, so I can't explore this on the machine yet, but:

specifying KINEMATICS_BOTH (kinstype= allows a gui to support jogging of each individual joint in joint mode. Caution is required for machines where the movement of a single joint (in a set specified by a duplicated coordinate letter) can lead to gantry racking or other unwanted outcomes. When the kinstype= parameter is omitted, operation defaults to KINEMATICS_IDENTITY (kinstype=1) and a gui may allow jogging based upon a selected axis coordinate letter (or by a keyboard key) before homing is completed and the machine is still in joint mode. The joint selected will depend upon the gui implementation but typically only one of the multiple joints in the set will jog. Consequently, specifying KINEMATICS_BOTH is recommended as it enables support for unambiguous, independent jogging of each individual joint. Machines that implement homing for all joints (including the provisions for synchronizing the final homing move for multiple joints) may be homed at machine startup and automatically switch to world mode where per-coordinate jogging is available.

"a gui may allow".  If I remove kinstype=BOTH then we could be back to what we're asking, to jog an axis together in joint mode?  I'm noting the term "may" allow, would the gui need something additional to do this?  I'll try tonight.

So the XHC is manually connecting to the joint.x component jog pins, we see that part and can reconfigure that easily.

Correct me if I'm wrong, but the HAL doesn't connect the keyboard to the joint.x components? I see no connection to fan out or add a logic gate to, so it's just hardwired into the system that the key will drive the joint component? I see where the joint is enabled, I could add a gate to just disable the joint. Is there a pin combination for "unhomed and not actively homing the system" to gate off the axis so the arrows won't drive it? I think the joint enable needs to be true for the HOME ALL cycle to work.