Hangs on G33/G76 command

I attempted threading for the first time today on my lathe. However, when it gets to the G76 line (or G33, alternatively), nothing happens, nor is there any error given. :huh: The program seems to "hang" and will remain "hung" until I hit the e-stop.

I do have a spindle tach, and EMC is reading it, and displaying the correct spindle speed, as I recently posted in another thread.

I note that the G76 documentation states that the pin "motion.spindle-at-speed" must be set up in HAL before G76 will work, and I don't see a "spindle-at-speed" line in my HAL. Do I need to add something to HAL?
linuxcnc.org/docs/html/gcode/gcode.html#...G76-Threading-Canned

Update: Hal-meter's "spindle-at-speed" is "false" when the spindle is turning and "true" when the spindle is not turning. Isn't that backwards of how it should be? How would I fix it?

Pretty sure motion.spindle-at-speed defaults to true so thats not a problem.

What _is_ missing is index (the encoder index pin is not connected)

Both G33 and G76 wait for the index pulse before starting spindle synchronized motion:

linuxcnc.org/docs/html/examples/spindle....d_spindle_feedback_a

If you only have a single sensor (and it has one count per turn) you should be able to do this:

net spindle-phase-a <= parport.0.pin-13-in-not
net spindle-index <= parport.0.pin-13-in-not

If the index polarity is wrong the correct statement would be:

net spindle-index <= parport.0.pin-13-in

PCW wrote: If you only have a single sensor (and it has one count per turn) you should be able to do this:

net spindle-phase-a <= parport.0.pin-13-in-not
net spindle-index <= parport.0.pin-13-in-not

The first line was already in my hal. I tried adding the 2nd line but then EMC gave me a boot error: Pin 'partport.0.pin-13-in-not' was already linked to spindle-phase-a'

Hmm... maybe this will work better

net spindle-phase-a encoder.0.phase-A
net spindle-phase-b encoder.0.phase-B
net spindle-phase-a encoder.0.phase-Z

Using my original Hal here are some quick and dirty Hal meter checks with the spindle turning:

spindle index ~ false
spindle index enable ~ false
spindle phase-a ~ toggles as spindle rotates
spindle phase-b ~ false
spindle position ~ gives a number
spindle velocity ~ gives a number
encoder.0.index-enable ~ false
motion.spindle-at-speed ~ true
motion.spindle-index-enable ~ false

It does appear that the spindle index is not doing its thing.

As discussed in another thread I had to set the spindle sensor up as phase A rather than as the spindle index, in order to make the axis spindle speed display work.

I am too much of an EMC newbie to understand how to make the Hal file happy with the index and the phase A at the same time. :laugh:

PCW wrote: Hmm... maybe this will work better

net spindle-phase-a encoder.0.phase-A
net spindle-phase-b encoder.0.phase-B
net spindle-phase-a encoder.0.phase-Z

As you suggested, changing the one line from: "net spindle-index encoder.0.phase-Z" to "net spindle-phase-a encoder.0.phase-Z" seems to fix my problems with no other changes. :woohoo:

Now G33 and G76 work, and the spindle speed display still works.

I did notice some unstable Z axis speeds during the threading pass at low (150 - 300 rpm) spindle speeds. This was discussed by another poster in another thread. He fixed his problem by adding "net spindle-position encoder.0.position-interpolated => motion.spindle-revs" but my Hal already had the "interpolated" feature and yet the Z speed was still "hunting" intermittently.

Increasing the RPMs to 500+ seems to make Z speed stabilize. Apparently it is a PID tuning problem in the software, and may be influenced by hardware as well?

Ironically, the reason I converted from TurboCNC to EMC was because TurboCNC also failed to maintain a consistent Z speed during low RPM threading. The only solution I found with TurboCNC was to crank up the RPM. Sigh. :S

I was told that TurboCNC only reads the RPM at the beginning of a threading pass, and then assumes a constant RPM for the duration of the pass, so I never understood why the Z speed needed to "hunt" in mid-thread. Why not just lock in a constant Z speed?

I dunno whether EMC reads the RPM only at the beginning of the thread, or whether it continues to read the RPM and continues to tune the Z speed in the middle of a threading pass? If it continues to tune the Z speed, that could explain the "hunting," especially with steppers that are not capable of changing speed quickly. Though once again, it seems to me it would be simpler for the software to lock in the Z speed for the duration of the pass? I mean, do you really expect the RPM to vary significantly over the course of a threading pass?

I pulled up my spindle index signal in the Hal scope and it looked clean and consistent, so the spindle index signal does not seem to be the problem. The indicated RPM bounces around maybe +/- 1 rpm, which is pretty good to my way of thinking and certainly no cause to adjust the Z speed in mid thread.