[SOLVED] Rigid tapping problem - tristate_bit and index-enable?

Wrapping up my mill rebuild and have run in to another issue.

Tried rigid tapping for the first time tonight and the spindle spun up to speed at the correct Z-height and just sat there spinning.  Obviously waiting for something that didnt happen.

First thought was  the spindle-at-speed signal.  Nope, that signal went high at the appropriate rpm, and stayed on despite a few rpm flutter.

Next culprit I suspect is the encoder index logic.  I know the encoder index signal/pin is working since spindle orient works OK.

Looking through my spindle HAL stuff, I remembered I had to use a tristate_bit pin to get orient functioning.  Because my spindle motor won't reliably orient on its own, I've had to add a pneumatic shot-pin to help stop it at the right spot.

Subroutine below, but basically I have to toggle the tristate_bit on & off, then rotate the spindle a rev or two to set the index.  Once that's set, shot pin is deployed and orient moves the spindle slow-ish until the shot pin drops in place.

Relevant HAL connections:


And the spindle orient/homing g-code:


Have I somehow hijacked LCNC's ability to set index-enable for G33 commands?

Do I need an or2 component somewhere so that something in LCNC can set the index-enable pin high for synchronized spindle moves in addition to the orient sequence?

Or should I be looking elsewhere for the tapping-won't-start problem?

I suspect you need to only enable the tristate when orienting
otherwise your digital output 07 will control index enable
rather than the encoder hardware for G33.

EDIT: Never mind, that does look like what you are doing.

Is motion-digilat-out07 false when you try to rigid tap?
 

PCW wrote:

Is motion-digilat-out07 false when you try to rigid tap?
 
 

Yes, digital-out is false when I try to rigid tap.

I haven't set up halscope to try to catch an index pulse or other brief signal, but the index-enable signal doesn't go true when I try to rigid tap.

EDIT - Minor troubleshooting update

I disconnected tristate_bit from motion-digital-out in halshow and ran a short tapping program to see if digital-out was holding the index-enable pin/signal false.

No change in behavior - spindle just spins & waits.

While it was spinning, I manually set the SPINDLE-INDEX-ENABLE signal high and all the nn.index-enable pins went high.
encoder.00.index-enable
pid.s.index-enable
spindle.0.index-enable

No change in behavior.

I did discover that I don't have pid.o.index-enable connected to anything.  I don't know if this is related to the tapping problem, but I wonder if it's the reason I had to do the tristate_bit gymnastics when I set this up a couple years ago.  IIRC, during orient attempts the spindle would just spin and nothing was triggering the index point.

I think I just found the point in history where I blew past the fact that pid.o.index-enable needed to be connected to something.

forum.linuxcnc.org/24-hal-components/458...-yay?start=40#245756

 

If you manually set the index enable signal true
and is is not over-driven by some other source,
it should get cleared at the index position by the
physical index signal. If this does no happen, you may
have a hardware issue with the index signal.

The index-enable is getting cleared when the index pin goes true.

Just tested that by disconnecting the tristate_bit and manually setting the index-enable signal high and running the spindle for a second.

It should still work with the tristate bit connected, as long as the tristate enable pin is false.

PCW wrote:

It should still work with the tristate bit connected, as long as the tristate enable pin is false.
 

Thanks, I'll reconnect it.

Shocking development: I've managed to get the spindle orienting without using the shot-pin, and without having to set index-enable true and rotate the spindle to re-find the index.

Based on Andy's advice a couple years ago, I had connected pid.o.error to pid.o.Pgain through a lincurve array.  After watching things in halshow today, I discovered that Pgain wasn't changing in response to the orient error; i.e. lincurve wasn't doing anything.

Turns out I had the lincurve starting x-values set to an order of magnatude smaller than required for lincurve to adjust the output.  Result was that lincurve didn't 'kick-in', ever.  The shot-pin was required to lock it in place because the pid wasn't adjusting - just causing the spindle to wag back and forth.

After changing the values and connecting pid.o.index-enable the spindle now orients from any position.  No shot-pin, no pre-orient spin-the-spindle index-enable dance.

Sadly, this hasn't fixed the rigid tapping failure.

O.M.G. - I should RTFM

spindle.M.revs IN FLOAT
For correct operation of spindle synchronized moves, this signal must be hooked to the position pin of the spindle encoder.

Ignorance is NOT bliss.