Czy można zrealizować prosty algorytm PID w prostym CPLD np:XC9572

Witam Czy waszym zdaniem da się to zrealizowac na prostym CPLD ? Czy wystarczy mu zasobów ? pozdrawiam

Reply to
Szumek
Loading thread data ...

Kiedyś popełniłem to na mikrokontrolerze PIC16F84. Kod w asemblerze był tak trywialny, że powinno wydać.

JanuszR

Reply to
JanuszR

Raczej nie. A czym chcesz sterowac ?

Do zapamietania sa 4 wspolczynniki, jakis akumulator czy dwa. Trzeba bedzie zrealizowac mnozenie, przydalby sie bufor do pochodnej, czesc obliczen trzeba bedzie z wieksza precyzja .. a tam sa tylko 72 bity.

No chyba ze na liczbach 6-bitowych ..

J.

Reply to
J.F.

to podejdźmy do problemu od inne strony sam algorytm pid wrzucmy do uC w CPLD zostawmy samo przygotowanie sygnałów dla uC czyli dekoder kwadraturowy, licznik i sumator 16 bitowy tyle to chyba wejdzie ? pozdrawiam

Reply to
Szumek

Użytkownik "Szumek" snipped-for-privacy@interia.pl napisał w wiadomości news:hf9bs4$7g$ snipped-for-privacy@atlantis.news.neostrada.pl...

a czy CPLD jest z góry narzucone ? bo jeśli nie, a widzę, ze coś mechanicznego popędzasz - spójrz na LM628/629 , z powodzeniem stosuję je od jakiegoś czasu.

@
Reply to
Artur Miller

Użytkownik "Artur Miller" snipped-for-privacy@nigdzie.pl napisał w wiadomości news:hf9amg$4dt$ snipped-for-privacy@news.interia.pl...

NIe jest do końca narzucone ale sam uC nie bardzo sie nada do obsługi enkodera CPLD zrobi to szybciej i nie zgubi impulsu napisz mi jeszcze przy okazji po ile da się kupić LM ? może być ciekawa alternatywą pozdrawiam

Reply to
Szumek

Użytkownik "Szumek" snipped-for-privacy@interia.pl napisał w wiadomości news:hf9e5h$get$ snipped-for-privacy@nemesis.news.neostrada.pl...

w TME po 140zł netto, Farnell 45?

@
Reply to
Artur Miller

Użytkownik Szumek napisał:

A z jaką maksymalną częstotliwością impulsów enkodera ma Kolega do czynienia? AVR poganiany zegarem 8MHz bez problemu radzi sobie z sygnałem o częstotliwości 50kHz w ramach obsługi przerwania. Jak dobrze zoptymalizujesz procedurę to i 100kHz pociągnie. A jeśli i to mało, to chyba wszystkie uC mają jakieś sprzętowe liczniki, które można zaprząc do roboty.

Oszacuj na początku jaka będzie maksymalna częstotliwość impulsów z enkodera, bo może się okazać, że wystarczy 8051 poganiany zegarem 12MHz :-)

Przykładowo: enkoder 1000imp/obr sprzęgnięty z wałem silnika mającego maksymalnie 3000obr/min.

3000 obr/min = 50 obr/s 50 obr/s * 1000 imp/s daje 50kHz czyli mała ATmega wystarczy. Jak ją jeszcze pogonisz na 16MHz to z zapasem.

Pozdrawiam Grzegorz

Reply to
Grzegorz Kurczyk

Użytkownik "Grzegorz Kurczyk" snipped-for-privacy@control.slupsk.pl> napisał w wiadomości news:hfafb2>

ale przydałoby sie, zeby ten procek coś jeszcze w międzyczasie robił :)

@
Reply to
Artur Miller

Użytkownik Artur Miller napisał:

Dobrze zoptymalizowana procedura przerwania do obsługi enkodera na AVR poganianym zegarem 8MHz wykonywała mi się w czasie 2,3us. Przy 50kHz obsługa przerwania zajmie prockowi niecałe 12% mocy obliczeniowej, więc nieco czasu mu zostanie na realizację innych zadań. :-) Przy zegarze

16MHz będzie to niecałe 6% czyli tzw. "pan pikuś" :-)

Pozdrawiam Grzegorz

Reply to
Grzegorz Kurczyk

Użytkownik "Grzegorz Kurczyk" snipped-for-privacy@control.slupsk.pl> napisał w wiadomości news:hfafb2$gc$ snipped-for-privacy@nemesis.news.neostrada.pl...

Witam ponownie już liczyłem to co kolega pisze mam enkodery już sprzęgnięte fabrycznie z servem mam takie co maja 250 imp /obr ale mam i takie co mają 2500 i 5000 i tu zaczynają się schody AVR już się nie wyrobi oprócz obsługi enkodera powinno byc miejsce na prosty PID i tak sobie kombinuje co by tu mądrego wymyslić

pozdrawiam

Reply to
Szumek

Dwa AVRki, tanio i prosto.

JanuszR

Reply to
JanuszR

Użytkownik "JanuszR" snipped-for-privacy@o2.pl napisał w wiadomości news:hfbq65$pm6$ snipped-for-privacy@news.onet.pl...

i miesiąc siedzenia nad softem, ktoremu czasem zdarzy sie pojsc w maliny i dźwig wjedzie w sciane ;) albo winda do nieba pojedzie ;) nie mowie, ze sie nie da, ale jesli to jakas cięższa mechanika, to ja juz bym się nie bawił w klepanie na piechotę i eksperymenty.

@
Reply to
Artur Miller

Użytkownik "Artur Miller" snipped-for-privacy@nigdzie.pl napisał w wiadomości news:hfbq4e$a9m$ snipped-for-privacy@news.interia.pl...

tez o tym myslałem żeby rozdzielić zadania ale raczej na CPLD + AVR przy 5000 imp/obr nawet 2 avrki chyba nie dadza rady więc narazie najlepszym chyba pomysłem jest cpld +uC (oczywiście dla silnika z enkoderem 5000imp/obr) koszt małego cpld ka jest tak niski że nawet niewarto zawracać sobie głowy jakimis zmianami mechanicznymi ze wzgledu na enkodery ) maszynka nie bedzie ciężka ani skomplikowana

Reply to
Szumek

Jakość softu zależy od ilości spędzonych nad nim godzin niestety :)

JanuszR

Reply to
JanuszR

Użytkownik Artur Miller napisał:

To się może zdarzyć również na fabrycznych "sprawdzonych" serwonapędach. Niedawno naprawiałem sterowniki ServoStar-a. Sterownik "fullwypas" procek 32bit, FPGA i mnóstwo innych kwadratowych scalaków z setkami nóżek, a taki prozaiczny wyschnięty elektrolit z zasilaniu spowodował, że gdyby nie krańcówki bezpieczeństwa odcinające zasilanie, to wrzeciono maszyny wjechałoby przez ścianę do drugiego pokoju :-)

Pozdrawiam Grzegorz

Reply to
Grzegorz Kurczyk

Użytkownik Szumek napisał:

Ale czy aż taka rozdzielczość jest Koledze potrzebna ?! 5000imp/obr to

0,072 stopnia. A jakie obroty ? W ostateczności można do obsługi enkodera zaprząc liczniki w AVRku. Korzystając z zewnętrznego licznika enkodera na jakimś CPLD trzeba jakoś ten stan licznika zczytać do procesora. Jeśli pojemność licznika ma mieć np. 32bity to musisz w CPLD zaszyć jakiś rejestr buforowy coby na czas transmisji zatrzasnąć bieżący stan licznika. Inaczej gdy w podczas przesyłania danych z CPLD do uC przyjdzie impuls z enkodera (co przy takiej rozdzielczości jest wysoce prawdopodobne) to uC może odczytać niezłą kaszankę.

Pozdrawiam Grzegorz

Reply to
Grzegorz Kurczyk

Użytkownik "Grzegorz Kurczyk" snipped-for-privacy@control.usun.slupsk.pl> napisał w wiadomości news:hfc17f$s37$ snipped-for-privacy@nemesis.news.neostrada.pl...

dlatego wlasnie, po takich przebojach, służąc doświadczeniem ;) zaproponowałem LM629 ... buforowanie rejestrów, gotowy filtr PID, wyjscie PWM, kilka ciekawych trybów pracy ... parę złotych więcej, ale o wiele więcej zaoszczędzone na czasie i skutkach błędów w sofcie.

@

PS. nie, nie pracuje dla Nationala :)

Reply to
Artur Miller

Użytkownik "Grzegorz Kurczyk" snipped-for-privacy@control.usun.slupsk.pl> napisał w wiadomości news:hfc17f$s37$ snipped-for-privacy@nemesis.news.neostrada.pl...

już kolegom odpowiadam

5000 imp /obr rozdzielczości mi nie trzeba myślę że 1000 jest w sam raz ale nie chcę rozbierać oryginalnych serv po to żeby wymienić im enkodery

mój pierwszy post miał mieć na celu zorientowanie się w możliwościach i problemach ponieważ z CPLD dopiero zaczynam trudno mi jest ocenic co wejdzie do takeigo układu a co nie czy jego sasoby pozwolą na stworzenie to o czym my tu piszemy czy nie ?

już mi się sprawa dzięki wam naświetla narazie wezmę mniejsze servo ze słabszym enkoderem i podziałam na avr z tym co mam dopuki nie wymyslę jak sterowac tamtymi

LM629 też jest ciekawą opcją ale warto poznać i pomyśleć nad innymi rozwiązanaimi

pozdrawiam

Reply to
Szumek

Co do CPLD - polecam poeksperymentować :)... ale tak "z góry" oszacować wymagania też się da. Podstawowy problem to ilość makrocel, a co za tym idzie też przerzutników... Musisz ocenić ile stanów ma obsługiwać urządzenie... jeśli robisz licznik - no to potrzebujesz tyle makrocel ile bitów ma licznik. Pamiętaj też o preskalerach częstotliwości (jeśli byś do czegoś potrzebował ;P) - to też są liczniki. Jeśli potrzebujesz buforować stan licznika - to podobnie znów drugie tyle bitów leci... jakieś sterowanie - powiedzmy SPI, jeśli typowe - to 8 bitów zużywasz na zapamiętanie sygnałów wejściowych/wyjściowych plus 3 bity, żeby policzyć do 8 ;)... to takie minimum... więc dla licznika 32 bity z buforowaniem i dostępem przez SPI potrzebujesz 75 makrocele... Lub więcej ;) Wszystko zależy na ile masz zaawansowaną logikę... w większości przypadków wystarczy logika "podpięta" do danej makroceli... Wówczas nie ma problemu. Gorzej, gdy któraś funkcja "rośnie"... i jest zależna od dużej liczby sygnałów... wtedy logika podłączona do innej makroceli zostaje wykorzystana do jakiegoś sygnału "wewnętrznego", albo połączona z logiką "sąsiednią" - i wtedy jakby maleje Ci liczba makrocel, którymi dysponujesz... Tak więc określasz minimum które potrzebujesz i pozostawiasz zapas. Warto także wybrać takie układy, które mają swoje większe odpowiedniki ;)... Ja się tak kiedyś wkopałem, wziąłem CPLD 64 makrocele w PLC44, nie starczyło miejsca i psikus, wersji 128 makrocel nie można było dostać w tej obudowie ;)... Warto projekt (prototyp) zrobić w większym układzie, gdy przejdzie testy, można śmiało w programie eksperymentować w który układ kod się wciśnie, a w który nie i później stosować już mniejszy (tańszy) układ...

Pozdrawiam Konop

PS Oczywiście makrocele to nie wszystko... miałem projekt, który "wchodził" w ukłąd XCR3064 (64 makrocel), a nie wchodził w układ XC9072XL (72 makrocele)... ale nie będę Cię zamęczać szczegółami ;)...

Reply to
Konop

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.