setting up threading with a missing tooth encoder on a lathe

Hello I am using linux 2.9 with a G0602 lathe im converting to CNC and already have the X and Z axis converted. I want to setup threading capability but am having issues (mostly I dont know what im doing or where to start from). Im using a 60 tooth encoder with 1 missing tooth with a parallel port breakout board. I have the two phase pins from the encoder (DAOKI LM393) running to pins 10 and 11 on the board. It reads the RPM but gives double the rpm, so when I set the missing teeth in the hal file to 2 it fixes itself. Then when I try to run a test g33 command it says "spindle not turning in g33". Im stuck and not sure how to proceed. I have attached the hal file to the post.

think first of all need to clarify to yourself encoder signal .... if you have 1 channel you can see Upper level and 0V level .... so 2 encoder signal .... with 2 channel you can see 4 encoder signal .... for better explain, normally a 2500 step encoder generate 10000 pulses every revolution .... so based on these you need to calculate reduction ratio too .... maybe 1 lathe revolution on 2500 pulses encoder have 10.000.000 of pulses ....

regards

sorry I dont quite understand. so each time it switches from low to high and vice versa is considered a encoder signal? since I have 60 slots (with one missing) that would mean my encoder scale should be 120?

add a additional sensor and give it 1 tooth for the Z or index pulse, and then use a 60 tooth wheel with all 60 teeth by adding the missing tooth back, OR turn it into a 30 tooth wheel, by removing every other tooth and then adding a second sensor at 30 degrees otomh. ORRRR get a cheap 600ppr encoder with a A B and Z pulse and put that on. I have a 1024ppr with A B and Z on my lathe, very good very nice.

I think there is a way to generate a fake index pulse every time the spindle completes a turn. So you could just use your 60 tooth encoder.
 You also need to set spindle.0.at-speed in hal.

you'd have to write a low level driver at the fpga and decode it with a tpu state machine, to have it be useful and low latency.

the output would be in degrees and distance, and it's definitely doable. the tooth period would get to short for a hal component with any significant rpm.

it's easier and more reliable to just use a standard a b z encoder.