Zrezygnowałem z przerwań, bo tylko wtedy miałem prawdziwy hardcorowy system czasu rzeczywistego - całkowicie przewidywalny, zawsze idący tą samą ścieżką.
Impulsy z LPT były próbkowane w pętli - w tej samej pętli były sprawdzane timery oraz wejścia komparatorów z mostków. Całość zajmowała kilkanaście instrukcji assemblera ( co przy 20Mhz zegarze daje 50ns/ instrukcję - całość poniżej 1us)
Po testach wyszło, że obsługa wejść/mostków/mikrokroku działa stabilnie do około 70-80kHz ( ograniczeniem był przetwornik C/A na SPI ).
Procki są tanie - następca tego projektu leży w szufladzie - zbudowałem go na 3x Mega88 ( razem około 18zł ). Jako że w swojej frezarce będę miał serwa ( krokowce sprzedałem) to ten projekt trochę poczeka na realizację.
[ Dodano: 2007-09-13, 14:13 ]
arizon pisze:Witam
W takim razie mam pytanie do Kolegi Jarekk jak to działa w UHU pytam z ciekawości bo wiem że UHU stosuje wiele osób z forum i oprócz Kolegi OLO, który wyciska wszystko z tego sterownika, raczej nikt nie narzeka. Pytam bo wiem że kolega już wiele przeszedł z różnymi mikrokontrolerami.
A co jak by sterownik zrobić na jakimś FPGA ? Czy one są mniej zawodne niż mikrokontrolery?
Pozdrawiam
Paweł
Można zrobić na FPGA . Tak naprawdę wtedy mamy doczynienia również z programem w np. VHDL, tyle że działającym równolegle.
FPGA jest nieco droższe ( ale niewiele 2,3 razy cena procka), dużo bardziej kłopotliwe w debuggingu (potrzebny jest np. analizator ), trudno dostać FPGA łatwo do montażu (dla nie mających odpowiedniego sprzętu). Większe FPGA potrzebują kilku napięć zasilania, zewnętrznej pamięci do konfiguracji
Ale za to oferuje prędkości nieosiągalne przez procki.
Tak naprawdę PID dla serwa nie potrzebuje wiele mocy - dlatego UHU wystarcza mały procek (sam algorytm PID dla częstotliwości pracy około 2kHz nie jest duży). Kolega OLO - na UHU narzekał długo. Głównie dlatego, że przycisnął UHU w jego najsłabszym miejscach:
- Enkoder kwadraturowy - robienie tego samplując piny ogranicza pasmo. U mnie ( dspic30F2010 ) w procku jest sprzętowy podukład - pasmo (w zależności od konfiguracji ) około 2Mhz
- Stopień mocy - UHU używa jednego sygnału do sterowania IR21xx. Z moich doświadczeń układy IR21xx są paskudne i jednak zawodne ( proponuje poczytać elektrodę). Mój obecny prototyp używa TLP250 ( optoizolowany sterownik mosfetów) oraz małego transformatorka aby zapewnić zasilenia po stronie mosfeta. Do pomiaru prądu kupię sensory Halla firmy ABB ( cena około 30zł ) - dostepne są wersje 20A lub 50A. To wszystko zapewni pełną galwaniczą optoizolację stopnia mocy - powinno to ograniczyć zakłócenia oraz w przypadku problemów zabezpieczyć procka. 30F2010 ma specjalizowany podukład do sterowania mosfetami - w zasadzie jest to "fire&forget". Można np. sterować czasem martwym (potrzebne dla IGBT/MOSFETów dużej mocy - IR21xx mają jedną stałą wielkość). Dodatkowo jest tam wejście 'error' blokujące sterowaniem mosfetów ( ustalające ich stan na wcześniej zaprogramowany) - u mnie podłączone do zabezpieczenia prądowego. W tej chwili nie mam tego jeszcze w programie, ale mam rónież podłączony pomiar prądu.
Kolega OLO podłączył do UHU dość poważne serwa - duża moc ( serwa wysokonapięciowe ). Zgadzam się z nim, że UHU nie nadaje się do takich serw. Co innego podłączyć serwo < 300W, napięcie < 100V - wtedy to działa.
Podsumowując - to wszystko można mieć w FPGA, ale prościej i taniej jest wziać specjalizowany układ zawierający potrzebne klocki i po prostu dodać kilka obliczeń PID. Myślę że procek będzie wykorzystywany tak w 20-30%
Jest to w zasadzie generalna zasada - póki starczy mocy, prościej jest wziąć procek niż FPGA