Wolę C, ale w C program chodziłby ~4 razy wolniej

Widziałem te układy. Są niestety nieco gorzej dostępne niż IR2184.
A problemy miałem z IR2184 dla aplikacji silnika krokowego - tam nie ma iskrzenia. Trochę układ pochodził - z zasilaczem o wydajności prądowej mniejszej niż wytrzymałość tranzystora - i padał zarówno tranzystor jak i driver . PCB było zrobione dość optymalnie, nie oszczędzałem na miejscu ani na grubości ścieżek. Używałem 100n ceraminczne + 100n tantal (dla IR2184).

Mógł to być problem mojej aplikacji - ale podobne poglądy dość często powtarzały się również na forum elektrody. Dlatego też moje następne konstrukcje nie będą używały IR21XX.

Mam już transformatory z ferystera ( dobrali mi gotowe ) - będę je kluczował ok 100kHz i zapewnią mi zasilanie TLP251 po stronie tranzystorów. Proste, bezpośrednie idiotoodporne (mam nadzieję). Biorąc pod uwagę ile spaliłem tranzystorów przy próbach - również tańsze.

W moim działającym rozwiązaniu był tylko jeden procek - tylko przetwornik C/A siedział jako slave na SPI.

W przyszłym rozwiązaniu jeden z procków obsługiwał sygnały z LPT. Na tej podstawie sterował przetwornikiem C/A oraz generował 6sygnałów sterujących dla pozostałych dwóch procków ( 3 sygnały dla każdego mostka H + napięcie referencyjne).

Każdy z mostków H był projektowany jako samodzielny moduł - jako wejście przyjmował napięcie 0.. 4.096V ( do sterowania prądem) 2 bity sterujace stanem mostka oraz 1 bit sterujący kontrolą pądu ( wygaszaniem).


Mogę Ci podesłać schematy / oprogramowanie tego co mam - da to pojęcie o projekcie.
Zaznaczam że soft został napisany w bardzo zoptymalizowany sposób w assemblerze wykorzystując procka do maksimum - podobny kod w C potrzebowałby na oko 4x tyle mocy.


Do mikrokroku nie trzeba dużo - ten pójdzie nawet w C.Kod programu byłby nieskomplikowany. Problemem są natomiast dobre rozwiązania mostka H. Można kupić gotowe ( ale tego kolega nie chciał), natomiast zrobine samemu na np. IR2184 nie chodziły mi stabilnie ( ukłąd jest kapryśny - nie do końca wiadomo czemu czasami odmawia współpracy ).

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

Kiedyś walczyłem ze zrobieniem falownika na mikrokontrolerze czyli zamiast kosciami robić sekwencje włączeń wyłczeń mosfetów robiłem to na uc. Było to coprawda kilka lat temu ale wówczas dominowały opinie w stylu ,że żadne urządzenia przemysłowe nie są bezpośrednio sterowane z uc, nawet jak uc posiada PWM to wykorzystywany jest do czegoś innego. Bo jak z jakichkolwiek przyczyn sie to zwiesi ,uc nieobsluzy przerwan(zabezpieczenia napradowe , przepieciowe itd.), będzie bład w programie to efekt łatwy do przewdzenia. Dlatego sekwencje pracy mosfetów lepiej sterować z wyspecjalizowanych układów.

Zrobiłem taki sterownik - na Mega88. Działał całkiem ładnie ale nie nadawał się do użytkou bo układy IR2184 ( sterowniki mosfetów) nie działały zbyt stabilnie ( głupiały i paliły zarówno siebie jak i mosfeta). Teraz robię sterownik serwo na dsPIC30F2010 - ma on sprzętowe wsparcie do obsługi mosfetów jak i sprzętowe zabezpieczenia mosfetów ( np. jest dedykowaane wejście 'error' które ustala stal lini sterujących mosfetami ). Do tego nieco lepsze sterowaie mosfetami - TLP251 + przetwornice


Do do sterowania mosfetami - sam PWM nie wystarczy - jeżeli chcesz poprawnie sterować mikrokrokowo . Poczytaj forum gdzie są rozważane A3977 lub inne projekty sterowników krokowców - żaden z nich nie używa czystego PWM'a. Ja implementowałem wszystko ręcznie w assemblerze - dopiero wtedy Meg88 działający w pętli ( bez przerwań) wyrabiał z zegarem do około 70kHz


Watchdog jest nieodpowiedni do kontroli pracy układu sterującego Mosfetami - musiałbyś dać naprawdę bardzo krótki okres 'kopania' - mosfetom naprawdę niewiele trzeba aby je upalić