Using a rotary encoder with a p/port

Ok I am retro fitting a small lathe using a p/port.

Q. will a 600p/rev single ended A+B+Z rotary encoder be too fast for a Chinese bob and what scale would be needed?

Would that count at 600 or 2400?

Yes I have used a a 60 pulse counter before with good results I might try and get a200 pulse the rev.
This would mainly be used for threading and probably never get above 600rpm

tommylight wrote:

Is it 60 or 600 ?
600 RPM should be doable with a nice margin even with a not so good latency.
Give it a try.

Yes it is 600 I have used 60 before with success for theading with just a slotted disk with 3 optos.

I will give it a go . I think I will have to put a filter on it if I can remember how to do it.

Update:
I am retrofitting a very small lathe Boxford with a Chinese simple bob. I have tried a 600 pulse/rev ABZ it's to fast for the P/port .

I have not tried a 200 P/rev single ended. It seems to count OK up to about 350 rpm I am not sure if it is missing the Z pulse the scale is set to 800 which seems to be correct tested with a rev counter.

Am I asking to much of the P/port with this ie. should I just put a simple 100 slot wheel with index slot.

To get a better Halscope view, you should set it to sample the inputs at the base thread rate rather than the servo thread rate

PCW wrote:

To get a better Halscope view, you should set it sample the inputs at the base thread rate rather than the servo thread rate

Thanks.
screen shots
1500rpm speed with tachometer

1000rpm

500rpm

250 rpm


Would this encoder be suitable for threading. Would you have an idea of the speed it could count at?

The speed on the axis screen is OK up to about 400 then it loses its way.

Yeah, I would say up to 250 RPM or so would be a good speed with some safety margin.

One way of looking at this is by calculating how many times linuxCNC samples each quadrature state

At 800 counts = quadrature states per turn and 500 RPM there are an average of 1.5 samples per state at 10 KHz.
While this exceeds the theoretical absolute minimum of 1 sample per state, it doesn't leave much margin for quadrature
errors or LinuxCNCs base thread timing jitter. Many quadrature encoders specify a 90 degree +-45 degree
quadrature error which would mean you would need to double the minimum number of samples per state
(to 2 minimum) to get a reliable reading

With 800 counts per turn and 2 samples per quadrature state and 10 KHz sampling, this works out to a
maximum RPM of 375 RPM. If you include host sampling time jitter, the 250 RPM figure seems good