Configuring and Homing dual Y Axes

1. Over the winter I modified my DYI Router Mill adding a tandem Y axis and rebuilding my Z axis support with a 2-DF gimbal  to true the spindle to the table. Today, I attempted to home the machine however, when the Y axes homed, one triggered before the other causing LCNC to complain about not being able to home one axis while the other is moving off the the home position.

What the the best way to resolve this issue such that both axes travel together, both for homing and moving off the home switch.

2. Using PNCCONF for configuring LCNC with tandem Y axes, when testing the Y axis only one of the steppers responds. Is there something that I missed in PNCCONF that will allow both Y steppers to be tested together?

3. What is the .ini PARAMETER that tells LCNC that two axes are in tandem?

Kind Regards,

In your INI file look for a KINEMATICS entry. Change XYZ to XYYZ to tell it you have two Y joints. Further down you end up with [AXIS_Y] but [JOINT_1] and [JOINT_2]. PNCCONF should have set this up for you.
The other important thing is that the two Y motors can't share a homing sensor input. You can share X and Y1 or Y2 and Z but not Y1 and Y2.
You may also need to reverse the rotation of one of the Y motors. How you do this depends on your hardware, of course.

Posting your hal/ ini files would help to pin down the issue.
 

.hal/.ini attached:

I've got both axes homing correctly though I did have to add 50 ms of debounce to all field inputs for everything to work correctly and consistently. Thanks for all your help.

I have to add debounce to my sensors, too, and I don't like doing it. I tried using probing moves to move "away" from the sensors, but that's too complicated. The problem with debounce.N is that it delays the signal (it's a low pass filter). Perhaps we need a different kind of debounce? Something that reacts immediately to the first edge, then ignores further edges for a while? That would trigger on the first hit, then ignore the bouncing, trigger on the first release, then ignore that bouncing, etc. That would make probing and non-probing moves more predictable without delaying anything.

Sigh, my brain couldn't help but try to fix this. My idea: change debounce() to act like this:

state in out action
neg 0 x state = -delay
neg 1 x state ++
zero 0 1 out=1 state = delay
zero 1 0 out=0 state = -delay
pos 1 x state = delay
pos 0 x state --

(if out isn't persistent, use state == +1 or -1 instead of zero)

I don't see a problem with de-bouncing a signal when homing since the purpose of homing is to put the machine in a known state and stop before doing anything else. If that takes an extra 50ms to insure the starting position of all axes, it is a non sequitur since the result is the machine is stopped. It might be a minor issues when hitting a limit switch while machining, but I'd rather error on fact rather than bounce.

Just my two cents worth.

The problem isn't the 50ms, it's that during that time the machine is *moving*. I.e. where you home depends on the bouncing of the sensor, which means it's unpredictable, which means every other position is also unreliable.
If you "hit" on the first contact, instead of waiting for the physics to settle down, you get a more predictable "moment" when the machine is in the known state.
You'd think it wouldn't matter, but I've seen my probe go measurably past the right spot before it "hits", and my probing routines actually probe in both directions (G38.2 then G38.4, and take the average) to try to eliminate this overshoot.
With a "first hit" debouncer, you could set the debounce time to 3 seconds and still get the right value.