Spindle encoder configuration (with G76 threading command and Mesa 7i96s)

I have a 600PPR quadrature encoder linked to my spindle with a 3:1 ratio, so 7200 PPR @ mesa spindle encoder input. A & B quadrature signals only, no 1PPR signal, but I don't think I need the 1PPR signal.

In Halshow
 - spindle.0.revs counts up as expected
 - spindle.0.speed-in appears correct
 - spindle.0.index-enable is disabled

in my SM-10.hal file I have: 
net spindle-index-enable      <=>  spindle.0.index-enable

IF I comment out this line, I can then enable spindle.0.index-enable manually in Halshow

Regardless when I try to open my 2 line G76 program I get the following error:
"Chosen spindle(0) not turning in G76"

I'm not sure if this is a HAL configuration issue or perhaps I need to do something in the gcode prior to the G76 command, not sure?

I have attached files for clarity.

Thanks,
Jeff


 

For threading, you need a 1PPR signal (index) from the spindle.

PCW wrote:

For threading, you need a 1PPR signal (index) from the spindle.

 

Before I swap out my present encoder that only has A & B 600 PPR quadrature signals with another one I have that has the A & B, as well as a 1 PPR signal. Is there any trickery in HAL I can do to use spindle,0,revs, that presently counts up 1 every spindle revolution, noting that spindle,0,revs is a float type value, so it slowly ramps up incrementally each revolution before it flips it's integer type digit.

Is the encoder on the spindle?
if not, the encoder index is not directly usable.

A single proximity/Hall switch on the spindle
could be added if this is the situation

It may be possible to use the spindle position
and some hal logic to simulate index operation
but it would not work well at higher speeds.
 and would forget position between LinuxCNC
runs,

 

PCW wrote:

Is the encoder on the spindle?
if not, the encoder index is not directly usable.

A single proximity/Hall switch on the spindle
could be added if this is the situation

It may be possible to use the spindle position
and some hal logic to simulate index operation
but it would not work well at higher speeds.
 and would forget position between LinuxCNC
runs,

 

 
I'm swapping in my other encoder, that has a 1 pulse per rev signal. The encoder is linked to the spindle with a timing belt, however there is a 3:1 ratio in the timing gears. So I will get 3 pulses per rev, is there a way to divide the Z count by 3 in Hal?

If necessary, I can fit an additional sensor for actual 1PPR

Its possible but awkward and complex

(because you need to hijack the index detection/enable hardware to count the (very short) index pulses)

Easiest thing  would be to add would be to add a 1PPR sensor on the spindle for index

Even better would be to add a 1 PPR sensor with a wide enough pulse that you could use
it as index mask (retaining the high precision of the encoder index)
 

PCW wrote:

Its possible but awkward and complex

(because you need to hijack the index detection/enable hardware to count the (very short) index pulses)

Easiest thing  would be to add would be to add a 1PPR sensor on the spindle for index

Even better would be to add a 1 PPR sensor with a wide enough pulse that you could use
it as index mask (retaining the high precision of the encoder index)

 

Okay, I'm printing a mount for a 1PPR right at the spindle. Please elaborate on the length required for the masking you describe. I could possibly stretch the short pulse . 

If you use a hall sensor as index mask, it will likely be wide enough as is,
but the wider (in degrees) , the easier to setup (because the
encoder index must happen within the 1 PPR signal)

If the 1PPR sensor is used for index directly, its width does not
matter.