Witam
na razie bawię się czymś innym ale wrócę do remory
nawet gdyby nie działało synchronizowanie indeksem g76 przy toczeniu ale
dało by się zrobić poprawny odczyt 3 liniałów
to mam dla niej zastosowanie

dobra to powiedz dokładnie co testowałeś w remorze
pod które piny podłączałeś enkoder A,B,C
który firmware wgrałeś remora-rt1052-3.1.4.beta.bin ?
które pliki pin próbowałeś np? ec500-rt1052-DMA-ENC.txt ?
nie synchronizowało w ogóle czy przy wyższych obrotach ?
czy widać było zmianę wartości pozycji w hal po obrocie enkodera?
czy numeracja-nazwy pinów IN nie była pozamieniana-przesunięta ?

Dodane 1 godzina 32 minuty 42 sekundy:
Witam
co zauważyłem , nie trzyma się autor numeracji pinów
jako enkoderowe wejścia się zgadzają , numeracja jako io są przesuniete o 4
podłączyłem na stole , co udało mi się uruchomić na szybko
dam rade odczytać pozycje 3 enkoderów ,(dobre i to )
ale na wejscia indeksowe nie reaguje w żaden sposób na żadne

Witam

rozkładam na czynniki pierwsze gwintowanie g76 i temat synchronizacji osi Z z wrzecionem
ogólny koncept mniej więcej znam , interesują mnie szczegóły takie jak:

-jak to jest zrobione dokładnie w mesie ?, z tego co wywnioskowałem ale nie jestem pewny :
to linuxcnc wystawia sygnał do mesy (index-enable) żeby ten wyzerował sprzętowy licznik w FPGA
tam licznik się resetuje ,linuxcnc dostaje gotową pozycję po resecie sprzętowym indexem jako już gotowe encoder.0.position
motion synchronizuje oś Z na podstawie tego sygnału , czyli mamy sprzętową synchronizacje po stronie mesy
następuje to przy każdym przejściu gwintowania g76

z kolei na temat remory wyszperałem to
w remorze nie następuje reset licznika sprzętowego tylko zatrzask
i przekazanie wartości licznika w chwili indexu do linuxcnc co 1ms
jako remora.PV.0 ,
następnie po stronie linuxcnc w (remora-eth-3.0.c)
jest korekcja o zatrzaśnięta wartość czyli czyli programowa korekcja synchronizacji
czyli teoretycznie remora też powinna poprawnie gwintować
(nie wiem czy nie są różnice w przekazywaniu indexu w róznych remorach )


i teraz mój przypadek (sprzętowo mam wejścia A,-A,B-B,C,-C do 1MHz to jest enkoder ethercatowy )
w tej chwili mam w halu co 1ms dostępne takie sygnały jak :
s32 raw-count czyli licznik surowy resetowany przy starcie zasilania lub programowo przez pin enc-reset
s32 raw-latch pozycja enkodera w chwili zatrzaśnięcia go przez sprzętowy index c,liczba jest niezmienna do następnego zatrzaśnięcia
float enc.count czyli pozycja po resecie sprzętowym przez index - to samo co position w mesa
enc.0.index-enable
czyli generalnie mam dostępne w hal takie piny jak w remorze aktualny i zatrzasniety i takie jak mesie po resecie

gdybym połączył w halu piny podobnie jak w mesie to wydaje mi się że gwintowanie powinno być poprawne jak mesą
szukam potwierdzenia lub zaprzeczenia lub naprostowania moich domysłów,
-test na żywo to sporo roboty

Witam
nie jestem specjalistą ani nie mam czasu na dogłębną analizę
ale pobieżnie chyba remora przesyła też informacje pozycji w chwili wykrycia indeksu sprzętowego na ec 500
czyli po poprawnym podłączeniu indeksu wpływ opóźnienia pakietów nie powinien mieć wpływu na gwintowanie

Witam
a jak jest rozwiązany temat indexu i gwintowania w mesie ?
tam chyba też częstotliwość przesyłania pakietów jest podobna

generalnie informacje przesyłane po skrętce są szybkie ale też nie gwarantują "real-time"
czyli generalnie chyba trzeba wysłać w pakiecie informację ostanie
licznika enkodera w momencie indeksu i dopiero na tej podstawie synchronizować gwintowanie
albo jakiś inny znacznik czasowy


może to zabrzmi jak herezja ale w tej chwili po LPT chyba lepiej synchronizuje indeks
niż przesyłanie samego indeksu w pakiecie po skrętce

Witam
o tym nie wiedziałęm :-/
do czego można wykorzystać sygnały opisane na płycie jako FHA, FHB, SRO ,SJR , WHA, WHB,
na złączu mpg też mamy dostępne z 6 wejść tylko
przez co one idą do uC na pcb ?
na razie swojej nie chce rozkręcać puki nie sprawdzę czy sprawna
generalnie problem synchronizacji może nie wynika z samego sprzętu
tylko komunikacji w wątku servo_thread, ( standardowy jest za wolny do przesyłania sygnału indeks )
z drugiej strony mesa też przecież komunikuje się praktycznie tak samo ,
wersja hardcorowa to mogę wydłubać filtry i pozamieniać pc 817 na szybsze bo są zamienniki ,
na kilku wejściach gdyby to coś dało
i pytanie czy da się bezpowrotnie uwalić uC poprzez błędne programowanie ?

Witam
płyta to ec 500 na rt1052, wersja pcb chyba ta sama co ty masz chociaż jeszcze nie rozkręcałem swojej ,
to odnośnie pytania o częstotliwość odczytu enokderów

muszę najpierw odpalić i zobaczyć czy w oryginale działa,
osi oczywiście że nie trzeba więcej, bardziej jako dodatkowe IO w drugiej szafie ,
chyba trafiłem na jakaś promocję bo mi wyszła 300 pln
taniej niż kable sygnałowe ekranowane między szafami elektrycznymi
wolałbym dopłacić trochę do kolejnej ec 500 i mieć wszystko w jednym stylu
niż dłubać się przy kolejnej płytce ,chyba że sprawdzony stabilny gotowiec
generalnie to swoje dłubanie muszę podzielić na 2 warianty
wersja 1 stabilna , sprawdzona , do większej frezarki
i 2 DIY tania , czasami jako zabawa , do małych zabawek
gdyby był potrzebny nie dało by się odpalić 2-giego pwma na wyściu zamiast osi c a filtracje już zrobić poza płytką?

Witam
czy testowałeś lub jesteś w stanie określić do jakiej częstotliwość płyta odczyta poprawnie impulsy enkodera ?
i czy ktoś ma remorę w środowisku wysokozakłóconym , czyli spore styczniki i spory falownik
czy wyszło coś po czasie?
i może durne pytanie ale czy da się teoretycznie 2 płyty ec 500 pod jeden linuxcnc?

Witam
dobrze by było żeby jednak pin wejściowy indeks do mikrokontrolera był jako opcja przyszłościowo chociażby
dobry byłby też pin zerujący od strony hal , można wtedy zerować jak ktoś tam sobie chce i kiedy chce
z homingiem czy w zależności od potrzeby, + enable w hal i więcej nic nie trzeba
+ jakiś pin przepełnienia albo licznik więcej niż 16 bit

Witam
nie śledzę dokładnie tematu , można kilka podpiąć przez switch ?
jak to by się sprawdziło jako czytnik liniału ,albo nawet 3 ?
cały czas mi chodzi po głowie czym tu by czytać liniały niż tylko mesą
generalnie kibicuję każdemu rozwiązaniu z komunikacją po skrętce
nawet takie się przyda co ma IO odświeżane z prędkością 300ms
pozdrawiam