Read encoder index using I/O

Hi,
I am using a 5i25/7i76 combo and would like to use the index pulse from encoders to home each axis. Is it possible for the I/O of the 7i76 to read push/pull index pulses or should I buy another daughter card with encoder inputs? I don't need to count A and B pulses by the way, just the index pulse.
Many thanks,
Guy Malpass

Theres no current way to do homing to index without having full encoder signals
If the drives are step/dir driven, the only easy way I can think of is to make a full
closed loop stepper system (stepgens in velocity mode, PID loop driving stepgens encoder position feedback)
this would require a encoder input daughter card

Cheers PCW, I did manage to find this: linuxcnc.org/dapper/index.php/english/fo...-switch--index-pulse

which seemed to be a solution to keeping the step/dir setup. The OP from the link writes as though his index is connected to I/O, possibly in line driver configuration? However I need differential due to the cable lengths involved. Is this possible with the 7i76?

Well it looks they use the encoder index input which would help with detecting the possibly very short index pulse
but its still not really correct since it doesn't not latch the count at the time of the index, so the move that searches
for index would have to be very slow.

Its easy to translate differential signals to TTL but more trouble to translate to the high level 7i76 field I/O

When you say its not really the correct solution is that because of the movement during decelleration after the index pulse is received? Presumably in a typical encoder setup that deceleration would have been measured from the A and B counts. If I've understood you correctly I may well end up going down the velocity mode route.
The reason im considering this is that I've been toying with the idea of using leadshine's closed loop stepper drives but still feeding an index to linuxcnc for accurate homing.

Homing to index is accurate for a couple reasons:
1. the index position on the encoder is very repeatable (typically less than 1 encoder count of error)
2. the encoder counter hardware latches the position at the exact time of the index pulse
allowing the index position to be accurately captured even when in motion

Any scheme using a standard I/O bit and not using the encoder counter will not be able to capture the
position when index occurs so will have a speed dependent offset.

In addition the servo thread sampling of the index input will result in +- (0.5 ms * index_search_velocity)
home position uncertainly. This of course can be minimized by slowing the index search velocity
(you may have to go very slow anyway to make sure the index signal lasts at least 1 ms so it can be
reliably detected by polling an input bit at the servo thread rate)

one possibility for reading the index signals:

If you are not using the 7I76's encoder input you can read the GPIO pins and get 3 differential input pairs

Firstly thank you for your comprehensive answers.
I've done a few quick calculations and a 200mm/min index search velocity would provide a good safety margin for the signal to be read using the 1ms polling with my encoder and gearing etc. At that speed; the errors and inaccuracies you've stated exist in the 1/1000th's of a mm for my setup which would be acceptable.
Regardless it appears there will be no easy way around this as the leadshine drives require 5v encoder inputs and the 7i76 needs at least 60% of 24v to sense a high signal using the GPIO. If I was to utilise the encoder input (the one that is intended for the spindle but unused in my setup) is it possible to connect mutliple encoders to it so long as one axis homes at a time and moves off the index before the next axis homes? I'm thinking along similar lines as HOME_IS_SHARED for multiple limit switches except with encoders?

the 7i76 has as a 5v supply for such as leadshines and encoders seperate from the Field power which can be anything from 12v - 24v for gpio
a suggestion is to add the pendant addon that will give you additional encoder inputs

i would bring the encoders back to the mesa cards , and not to the drivers , that is meant more for systems to imitate a semi closed loop system
whereas with linuxcnc you have a full closed loop system available , so you have benefits to use it

which particular model of driver are you thinking of using ?

How many index signals do you have?

The 7I76 has 4 differential inputs available if unused for their primary purpose:

encoder A,B,Idx, SSerialRX

CNCbasher - The driver model would be ES-DH2306, however I am starting to lean towards a velocity mode setup.
PCW - I would start off with three index signals, possibly going up to five in the future. I hadn't considered using the A and B channel inputs for indexes and certainly not the SSerialRX.

What I'm aiming to achieve is to modify my stepper setup so that:

• the position is monitored hence giving me the confidence to run it over night for example
• the machine homes using index signals
• the gantry self squares on homing

My initial plan was to close the loop in the driver and take the index signals into a custom component whereby the step signal to one of the motors was broken while the other kept running to square itself.

From what you Gentlemen have told me I think I should instead buy another daughtercard for more encoder inputs and close the loop in linuxcnc, then use gentrivkins for the gantry.