Poza tym że wprowadza nieścisłość ...
Bo kojarzy się automatycznie z wyjściami bez negacji czyli 3 druty tak jak większość samoróbek (choć też nie do końca, bo większość samoróbek ma 3 druty jako wyjścia OC co jest jeszcze gorsze z punktu widzenia odporności na zakłócenia; mało kto daje scalaka na wyjściu który robi im wyjście typu push-pull), albo część tańszych enkoderów.

Czyli miałeś enkoder z wyjściem różnicowym z którego nie skorzystałeś, a nie enkoder z wyjściem TTL jak pisałeś w pierwszym poście...
Jeżeli zakłócenia były powodem nie działania indeksu to te zakłócenia tak samo działały na pozostałe kanały.
Przy kilkumetrowym kablu oczywistym jest że trzeba puszczać różnicowo tak wątłe sygnały.

Jak Ci szkoda czasu na próbowanie z układem przedłużania impulsu to zrób sztuczkę taką że mechanicznie masz zamontowane dwa enkodery, z fabrycznego puszczasz A, B, a z samoróbki indeks. Na 90% będzie działało dlatego że okienko będzie dłuższe, więc indeks zostanie zauważony.


Trochę wyrwane z kontekstu (aczkolwiek zbliżonego do postawionego tu problemu):

"There is hardware in the encoder counter that can watch for index and clear the encoder
counter when its detected. This in the normal way homing to index is done with hardware counters.
This has the advantage that you can't miss the index pulse no matter how fast the homing
sequence is or how high the encoder resolution is (index is normally only one count wide)"

Inna ważna informacja:
2. Maximum encoder read rate with software is 1/(BTP+BTJ) for perfect quadrature. If we allow 30% quadrature distortion this becomes .7/(BTP+BTJ), where BTP is base thread period and BTJ is maximum base thread jitter. So for example if you can manage a 50 KHz base thread with 5 usec of jitter you get a maximum count rate of 28 KHz. Note that this may be quite limiting, for example with a 500 line encoder (2000 counts per turn) this limits you to 880 RPM. Sofware encoder counting works fine with low resolution encoders such as would be useful on a spindle

Różnie, standardem jest 2500 imp/obr, czasem 10000 imp/obr.
Ale tam masz sprzętowy odczyt a tu programowy, tzw. pooling więc ma prawo nie zauważyć indeksu.

Zbyt krótko trwa index. Linuxcnc tego nie wyłapuje. Niech Ci któryś z chłopaków dorobi przerzutnik monostabilny z przedłużaniem impulsu wyzwalającego.

Przy samoróbce miałeś duże okienko a tu jest małe, przez co indeks trwa zbyt krótko i nie łapie linuxcnc synchronizacji.

[ Dodano: 2014-01-31, 20:11 ]
Ewentualnie masz zakłócenia których czas trwania jest porównywalny z indeksem, ale chyba to nie to więc spróbuj przedłużania impulsu bo obstawiam że jest zbyt krótki. Koszt to 5zł za scalaka i parę oporników oraz kondensatorów.
Możesz też popróbować z bramkami z wejściem schmitta, choć tu chyba są zbędne przy tego typu enkoderze.

Ile impulsów na obrót ma?
Jeżeli więcej niż 400 to mogą już być problemy bo przy wyższych obrotach częstotliwość impulsów jest na tyle duża że sczytywanie enkodera przez zwykłe lpt staje się problemem.
Dlatego dobrze sprawdzają się enkodery które mają nie więcej niż 100-200 kresek.

Sprawdź gwintowanie przy obrotach wrzeciona zmniejszonych do 40-60 obr/min. Jest duża szansa że wtedy nie będzie gubił synchronizmu, a to będzie oznaczało że masz zbyt dużą rozdzielczość enkodera.

Druga kwestia to ewentualne wyjścia enkodera typu TTL lub co mniej prawdopodobne (bo już samoróbka Ci działała) zakłócenia.