Optoizolacja LPT - następne wcielenie ...

Transoptory serii CNY i podobne są absolutnie wystarczające do tego zastosowania. Przy okazji kosztują chyba poniżej złotówki na kanał.
Przy tej aplikacji nie ma sensu rozglądać się za niczym szybszym. Z resztą wszystkie bez wyjątku optoizolatory z fototranzystorem po stronie odbiorczej są wolne.
Ursus, takie firmy jak Analog, LT, Maxim, Burr-Brown, PMI, produkują podzespoły o jakości o którą ST się nawet nie ociera. Dyskusja na ten temat nie ma żadnego sensu nawet. Do popularnych celów używa się popularnych układów. Do celów o wyżyłowanych parametrach nie ma opcji, żeby zastosować cokolwiek od ST. ST nawet nie specyfikuje większości pomniejszych parametrów, które w poważnych zastosowaniach mają kluczowe znaczenie.
Allegro to firma produkująca niszowe układy. Intersil to taki producent "pomiędzy". Jak Microchip czy Toshiba. Coś tam można u nich fajnego wygrzebać w niektórych grupach produktów.
Ceny układów o zbliżonych parametrach są również bardzo zbliżone u wszystkich producentów. Po prostu taki Analog czy Maxim mają wyroby, których nie ma nawet zbliżonych nikt inny, i za to już trzeba zapłacić. Po prostu trzeba wiedzieć u kogo czego szukać.
Analoga w Polsce prowadzi Alfine. Minimalka to opakowanie zbiorcze. U detalistów ceny są chore.
Markcomp, ADUM-y są bardzo dobrze dostępne. Po prostu TME ma na magazynie i w ofercie to co im schodzi. A ponieważ większość ludzi w Polsce ma takie podejście jak Ty , więc przy kryterium najniższej ceny takie produkty nie mogą być popularne.

mc2kwacz pisze:ADUM-y są bardzo dobrze dostępne. Po prostu TME ma na magazynie i w ofercie to co im schodzi. A ponieważ większość ludzi w Polsce ma takie podejście jak Ty , więc przy kryterium najniższej ceny takie produkty nie mogą być popularne.

nie mam jakiegoś konkretnego podejścia do tej firmy...
doceniam noty katalogowe... piękne obrazki...
doceniam takie fajne proste aplikacje jak LTspice (choć to chyba nie ta firma...)
układy dobieram podług potrzeb...
może kiedyś zdarzy się zapotrzebowanie również na układ tej firmy...
nie rozumiem jednak szufladkowania... ale lubię słuchać przeciwstawnych sądów
---

skoro jesteśmy przy porcie lpt, to może rzucę zagadnienie, które troche ostatnio analizuję
https://www.cnc.info.pl/topics54/serwok ... ht=#360234

opisany układ fpga jest ładowany z portu lpt.. a następnie jest akceleratorem szybkich zadań.. np. generacji pulsu (ze 300kHz), lub obsługą gęstego enkodera

zastanawiam się... jakie fpga są na dzień dzisiejszy łatwe do zaakceptowania w takim projekcie... czyli jest dostępne oprogramowanie (verilog itp), zgodność napięciowa z tym co jest w w lpt(5V np.)... no dostępność + cena (TARGET-->>cnc-garażowe)

ACEX zastosowany w pluto jest nieco stary... niby jeszcze można go kupić, ale w najnowszej wersji softu już go niema...

pozostaje jeszcze kwestia zakłóceń przy transmisji z LPT do gołego fpga...

Pytanie czemu to ma służyć? Chyba nie linuxcnc, którego główną zaletą jest bycie systemem czasu rzeczywistego. Z takim "akceleratorem" sam linux przestaje być systemem czasu rzeczywistego. I wtedy każdy inny program jest równie dobry, bo główny ciężar obsługi osi tkwi w sterowniku zewnętrznym i to on dyktuje relacje czasowe.
Ładowanie takiego sterownika równoległym portem też jest bez sensu pomysłem, bo to niewygodny interfejs i zupełnie zbędny przy zewnętrznej obsłudze real time i przy dostępności szybkich portów szeregowych. Łatwiej też o problemy spowodowanie usterką połączenia. W tym momencie dochodzimy do rozwiązań w stylu megaplot albo piko.
Problem zakłóceń i w ogóle poprawnego działania układu, to problem klasy przedszkolnej.

Nie za bardzo rozumiem też nacisku na hasło fpga. Dlaczego fpga i cały ten majdan z nm związany??? A czemu nie zwykły jednoukładowiec, który nieporównanie łatwiej oprogramować i spokojnie sobie poradzi. Można sięgnąć nawet po jednoukładowce sygnałowe, pieruńsko szybkie.
na dobrą sprawę, całą obsługę maszyny cnc na dzień dzisiejszy można upchnąć w takim małym chipie. Program sterujący pecetowy może się ograniczyć do przesłania parametrów wektora. A jak się uprzeć, to i do przesłania nastaw konfiguracyjnych i potem gotowych gkodów, choć to oczywiście dużo więcej roboty, żeby było zrobione dobrze.
Tylko po co, skoro są gotowe rozwiązania i nie kosztują wiele...

mc2kwacz pisze: Z takim "akceleratorem" sam linux przestaje być systemem czasu rzeczywistego

nie przestaje...
Architektura HAL linuxcnc składa się z modułów HAl takich jak generatory, enkodery, pidy itp...
Moduły te łączymy "kabelkami" w pliku konfiguracyjnym hal, tworząc dowolną kinematykę maszyny...
Każdy z modułów może być kawałkiem programu siedzącym w PCecie... albo kawałkiem programu siedzącym w uC w czasie rzeczywistym podłączonym z Pcetem.. albo kawałkiem sprzętu (np. fpga)

Tworząc akceleratory (czy to fgpa,pld.. czy uC) wpasowujemy się w architekturę HAL...

--
dlaczego port LPT jako interface czasu rzeczywistego?

Dzisiaj.. każdy inny dostępny interface wymaga "nadzwyczajnego" łatania jądra

Jutro.. wszystko może się zmienić... jądro dystrybucji linuxcnc będzie uzbrojone również w czas rzeczywisty dla ethernetu... a to pozwoli zastosować ten interface


--
Struktura fpga na "płycie głównej" może zostać inaczej zaprogramowana jak dla linuxnc... może stworzyć filtr do zakłóceń, albo coś w rodzaju PLL dla przesyłanych sygnałów STEP... możliwości jest
wiele

--
uC na płycie głwnej zwłaszcza łatwo programowalny to również dobry pomysł...
np. Arduino due -- bardzo łatwe środowisko programowania, a procek zawiera wszystko co trzeba...

Powtarzam po raz kolejny, że w momencie w którym system mikroprocesorowy traci BEZPOŚREDNI kontakt z relacjami i czasowymi zachodzącymi w układzie sterowanym, W TYM MOMENCIE przestaje być systemem czasu rzeczywistego.
Możesz mieć 99% logiki umieszczonej w pececie. Ale jeśli takt czasowy dla maszyny będzie fizycznie wytwarzany przez dowolny układ zewnętrzny, i ten układ zewnętrzny będzie również przesyłał sygnały zwrotne w nierzeczywistym momencie ich wystąpienia na maszynie, to systemem czasu rzeczywistego staje się układ maszyna-proteza. Innymi słowy centralny system mikroprocesorowy traci posadę składnika systemu czasu rzeczywistego na rzecz protezy, i przyjmuje rolę układu pomocniczego. Nie szkodzi, że o nadrzędnej roli obliczeniowej. Z punktu widzenia systemu czasu rzeczywistego jest to rola podrzędna. Dlatego, że sygnały czasu rzeczywistego mają zawsze priorytet (z dokładnością do dopuszczalnego przesunięcia).
System traktowany jako całość oczywiście cały czas może być nazywany systemem czasu rzeczywistego. Tak samo jak tokarka z Fanucem jest. Ale w tej strukturze pecet i to co na nim, traci ten przymiotnik. Tak samo jak nie wszystkie procesy zachodzące w Fanuc są realizowane w czasie rzeczywistym. Różnica jest jednak zasadnicza - w Fanuc budowa struktury odpowiada za pełną funkcjonalność główną w czasie rzeczywistym (to co powinno być realizowane w real time jest bezwzględnie realizowane w real time) a w systemie z linuxcnc realizacja tego jest niemożliwa z powodu sprzętowych ograniczeń zastosowanej maszyny cyfrowej.
Już op tym rozmawialiśmy kilka razy, że linuxcnc jako bezpośredni składnik układu czasu rzeczywistego, "kończy się" na częstotliwościach I/O dochodzących w porywach do 25kHz (przy słabym pececie 5-10kHz). Wszystkie akceleratory w postaci kart rozszerzeń to są już autonomiczne układy (z punktu widzenia czasu rzeczywistego).

Układ nadpróbkujący tylko i wyłącznie wtedy działa poprawnie, kiedy dokładność chwilowa zegara taktującego (jitter) odpowiada rozdzielczości układu nadpróbkującego. Możesz miernikiem częstotliwości z głównym zegarem 1kHz, zmierzyć 1GHz z rozdzielczością do 1Hz zawsze. Ale z DOKŁADNOŚCIĄ do 1Hz tylko wtedy, gdy zegar główny będzie miał DOKŁADNOŚĆ lepszą niż 1ppm, czyli siedmiocyfrową.
Jeśli linuxcnc ma jitter odpowiadający częstotliwości 25kHz, to nadpróbkowanie protezą sygnału step nie poprawi nierównomierności w cyklu równym częstotliwości głównego wątku. Proteza będzie to musiała uśrednić po kilku okresach. I w ten sposób coraz bardziej oddalamy się od systemu czasu rzeczywistego z punktu widzenia linuxa.

Konkluzja jest oczywista - linuxcnc kończy się na 25kHz a chcąc mieć coś FAKTYCZNIE lepszego, trzeba sprawić sobie coś lepszego do sterowania. Dla porównania Sinumerik 3 sprzed ponad 30 lat obsługuje wszystkie sygnały wejścia-wyjścia (w tym enkodery kwadraturowe) z częstotliwością sygnałów wejściowych do... 200kHz. Ponad 30-letni kopalny "rzęch" jest 10x lepszy od linuxacnc na najnowszym pececie! Również pod względem precyzji.
Co tu można dodać...

Protezowanie niedostatków różnych rozwiązań ma zwykle bardzo ograniczony sens. Są takie rozwiązania, że inaczej się nie da, jest to jedyna droga do jakiejś tam poprawy, gdy technologia doszła do ściany. Ale protezować na siłę coś, co spokojnie można zastąpić czymś innym, "naturalnie" lepszym? Tylko jeśli świadomie godzimy się na "nibyjakość". Za niewielką cenę można sobie co najwyżej dokupić lepsze samopoczucie.

witam.
wywód jasny .
z tym 1ppm dla 1 giga to chyba nie tak - chyba że się mylę.
potrzebna chyba większa dla dokładności 1Hz.
w końcu 1 giga to 1000MHz.
albo mi się coś pokićkało.
pozdrawiam.
dodając - konkluzja też jasna - wyżej d..y nie podskoczymy

Tak, oczywiście masz rację, przejęzyczenie. Powinienem napisać "mega". Albo, zostając przy giga, lepiej niż 0,001ppm czyli 10 miejsc znaczących.
Megaherc z bezwzględną dokładnością do herca da się zmierzyć bez problemu byle lepszym skompensowanym termicznie generatorem kwarcowym. Żeby zmierzyć gigaherc z dokładnością do herca, trzeba już dobrego wzorca niskoszumnego, na dodatek solidnie stabilizowanego termicznie.

mc2kwacz pisze:. Ponad 30-letni kopalny "rzęch" jest 10x lepszy od linuxacnc na najnowszym pececie!

Rzecz gustu. A ja bym się nie zamienił, chyba ze za dopłatą równą różnicy w cenie obu rozwiązań
Na wiosennych targach testowałem tokarkę uniwersalną z Fanucem - tak to można robić za karę.

ciekaw jestem jaka jest częstotliwość zmiany wektora prędkości w tych Fanukowych kontrolerach ruchu?...
--

trochę przeciągamy dyskusję nie związaną z tematem wątku...
rzuciłem zagadnienie związane z pluto dla przeprowadzenia dyskusji związanej z portem LPT, który jest związany z tym wątkiem... i wspomniałem o ciekawej możliwości odzyskiwania kiepskiego sygnału STEP/DIR (nawet z winy komputera) przez wystarczająco szybką dla celu strukturą fpga ...

Fanuc to jeden z wielu sterowników cnc. Może się nie podobać, są inne. Wszystko jest kwestią przyzwyczajenia. Ważny jest efekt końcowy oraz codzienna łatwość obsługi. Często narzędzia z pozoru bezsensowne i nieintuicyjne po bliższym poznaniu okazują się zaskakująco wygodne i właśnie intuicyjne. Jeśli ktoś przyzwyczajony do linuxacnc stanie przy sterowniku dedykowanym, to nie ma szansy żeby od razu się przekonał. Nawet szukanie guzików na
"telefonicznej" klawiaturze jest problemem. To się nazywa 'bezwładność masy ludzkiej'

Nie ma się co zamieniać. Ale nie ma tez żadnego sensu próbować "modernizować" maszynę ze sterownika dedykowanego do linuxa, bo to nie jest żadna modernizacja tylko krok w tył.
Dedykowany sterownik zrobi na tokarce dokładnie wszystko czego dusza zapragnie, wliczając w to automatyczne cykle zdejmowania warstw, gwintów, stożków, rowków. Byle tylko nóż był w stanie podejść. I zrobi to absolutnie niezawodnie, bez jakiegokolwiek ryzyka zgubienia kroków czy podobnych zdarzeń. Można sobie napisać procedury lub nawet funkcje do powtarzanych nietypowych operacji, i nawet opisanie dość skomplikowanego kształtu z palca trwa wtedy parę chwil. Czego chcieć więcej w zwykłej maszynie skrawającej?

Główny temat wątku już dawno się chyba wyczerpał.