g76 canned threading using NGCGUI sub routine

I copied a number of Johns routines from the library and have them setup on my cnc lathe. I'm AIR testing everything and have AIR tested the od, drill and taper subs and they work fine .i.e they move and cut in the correct directions watching the toolpath linuxcnc provide. The problem is I can't get the G76 sub to run properly even cutting AIR. I have my tool table setup and running with the other subs so it appears to be working and setup properly. I believe I have my synchronized motion setup properly because I have a stable smooth RPM meter on the panel using an index pulse and the 100ppr quadrature encoder running and have verified it has stable output on phase A and phase B using halscope.

I need assistance with the two items below.

1) I'm not sure how to test if the synchronized motion is working properly since it mainly used for threading?
2) The g76 sub routine starts out OK and moves the tool to the proper position to start threading from home but then it just stops without even attempting to cut AIR threads. I can see the tool path lines for threading setup on the display to the tool path looks valid. However I'm not seeing any errors why the canned threading stops. I have to manually stop it or it will just sit there. I have verified the contents of the g76 sub routine and it's ok, even copied it again and replaced the first one.

How do I trouble shoot this with no error codes?

Thanks,
Dave

It's amazing that as soon as I post a thread for help I figure out what's wrong. I played around with inverting the par pins connected to the index and phase a & b. Once I found the right combination I have threading.

This is also missing from the documentation for running a encoder with quadrature output. The line below isn't in any of the synchronized motion docs and the step config wizard doesn't add it to the hal file even though you have assigned a parport pin to phase b. I just stumbled on it when searching for the G76 stalling problem.

setp encoder.0.x4-mode true

The same thread also suggested putting the "not" for the parport when the G76 stalls the moment the tool tip touches the work piece. This would save people quite a bit of trouble when setting up an encoder using both phase A & B.

net spindle-phase-a encoder.0.phase-A <= parport.0.pin-11-in-not
net spindle-phase-b encoder.0.phase-B <= parport.0.pin-12-in-not
net spindle-index encoder.0.phase-Z <= parport.0.pin-13-in-not

John,
I looked and couldn't find it again without spending a bit more time.

Remember I'm running AIR threading but I can get your G76 coding to work by either.

This:
net spindle-phase-a encoder.0.phase-A <= parport.0.pin-11-in
net spindle-phase-b encoder.0.phase-B <= parport.0.pin-12-in-not
net spindle-index encoder.0.phase-Z <= parport.0.pin-13-in

Or this:
net spindle-phase-a encoder.0.phase-A <= parport.0.pin-11-in-not
net spindle-phase-b encoder.0.phase-B <= parport.0.pin-12-in
net spindle-index encoder.0.phase-Z <= parport.0.pin-13-in

If one of the phases inverted the G76 threading will stop the moment the tool point touches the work piece after moving from home.

I can also change the phaze Z to -in-not as long as I have one of the other two pins coming from the encoder inverted and it appears to work either way. I guess I won't know if it's really working or not until I actually try cutting some threads. I suspect my encoder www.lynxmotion.com/p-448-quadrature-motor-encoder-wcable.aspx requires this because of the way I have it physically mounted to my mini-lathe.


Running the spindle in the CW direction (picture view) forces the encoder to run in the opposite direction which causes the quadrature phase b to lead phase a. I'm going to assume that linuxcnc requires phase a to lead phase b which is what I'm doing by inverting one of them.

I needed the spindle bore open so the way I mounted the encoder was the easiest way I could think of and the parts were cheap to do so.

John,
Yes the single sensor is my index and it is geared 1:1.

I can get the motion.spindle-index-enable to go true by using your method but it doesn't change when I rotate the spindle manually, it stays true regardless. Is this pin supposed to change states when the spindle-index pin changes states? I've verified that is happening every time the sensor hits the slot on the disk. My spindle sensor is a C3 board from cnc4pc.

The signal you want to setp and watch is encoder.0.index-enable

(which should normally be linked to motion.spindle-index-enable in the HAL file)