Uk?ad fail-safe

Witam,

Poszukuję schematu prostego układu fail-safe, ale nie opartego na mikrokontrolerze Microchip (Atmel może być). Wszystkie programatory PIC'a które znalazłem wymagają wysokiego napięcia do zaprogramowania, a mam tylko zasilacz 5V i programator ISP dla kontrolerów Atmel'a. Może ktoś posiada taki schemat i mógłby go udostępnić?

Reply to
AdMiNeK
Loading thread data ...

Użytkownik AdMiNeK napisał:

Hint: zasilacz PC daje 12V

Reply to
AlexY

mikrokontrolerze Microchip (Atmel może być).

Prosisz i masz:

formatting link
Schemat jest bardzo prosty. Najtrudniejszy jest program (firmware) i w nim jest cała tajemnica układu.

Kończę właśnie przygotowywać taki układ do serwyjnej produkcji. Pierwsze, prototypowe układy za 2 tygodnie. Jeśli chcesz, to Ci sprzedam Ci jeden z prototypów z zainstalowanym programem. W skrócie:

- Atmel AVR ATMega32

- 8 kanałów

- rozdzielczość serwomechanizmów: 2048 kroków

- gniazdo programowania Kanda ISP

- gniazdo autopilota RS-232 TTL

Cztery tryby pracy: - "przezroczysty" - tak, jakby nic nie było pomiędzy odbiornikiem i serwami - "fail-save" - przy zaniku sygnału układ ustawia serwa w pozycji z chwili uruchomienia układu - "RS-232" - wejście z odbiornika jest odcięte, serwami steruje się przy pomocy protokołu RS-232 (pełny protokół z sumami kontrolnymi BCC, powtarzaniem ramek itd) - "Autopilot" - (właściwy tryb, dla którego ten układ był projektowany) - normalnie układ pracuje jak fail-save. Równocześnie ciągle próbkuje kanał nr 8. Gdy kanał wejdzie w "stan wysoki" (nie w rozumieniu TTL, lecz sygnałów PWM), to na gnieździe EXT autopilota podnosi się RTS, co jest sygnałem dla autopilota, że "teraz ty sterujesz". Wówczas układ pracuje jak w trybie RS-232 do czasu przełączenia kanału w "stan niski". W tryb autopilota układ przechodzi automatycznie w przypadku braku sygnału z nadajnika.

Reply to
Lukasz

Witam użyłeś aż tak potężnego procesora ? może ATmega8 by wystarczyła ? Marek S

Reply to
Marek S

Witam pomyślałem ze możliwe ze sobie cos takiego zrobię ale inaczej

1- procesor zapamiętuje ustawienia przy starcie 2- przy impulsie z odbiornika procesor nic nie robi 3- przy braku impulsu np. 1 sek. procesor wyłącza odbiornik i wysyła na serwa sygnały zapamiętane . 4- przy ponownym pojawieniu się sygnału wraca do czuwania . Marek S
Reply to
Marek S

Dnia 04-02-2007 14:30, Użytkownik Marek S napisał:

Nie dość, że się napracujesz, to przy zakłóceniach rozwalisz model. Układ musi wciąż badać nie tylko czy jest sygnał, ale również czy jest on prawidłowy. Kup sobie REX MPD - nic nie będziesz musiał robić. Mariusz.

Reply to
Bonawentura

Atmega8 ma niekorzystny układ wyprowadzeń. Od biedy pewnie by wystarczyła.

16 i 32, to bardzo podobne procesory, więc w razie potrzeby można zmienić na
  1. atmega32 mam dobrze przetestowaną i opanowaną. Różnica w cenie, to 3-5 zł. W rozmiarze, to 3mm. Powodów jest wiele, nie chce mi się przytaczac wszystkich.
Reply to
Lukasz

To dokładnie to samo, co u mnie w trybie "fail-save".

Zawsze można kupić gotowy układ w sklepie. Ale to "damskie" zachowanie. Gdyby nie było na świecie eksperymentujących facetów, to technika zatrzymałaby się na 1 w. n.e. Zawsze istnieje ryzyko, ze kogoś zabiję modelem, ale bez ryzyka nie ma postępu.

Zgadzam się. Badanie poprawności sygnału, to zawiły temat. Cholernie się z tym namęczyłem. To samo z płynnym sterowaniem serwami. Tak, jak napisałem: cała sztuka w programie. Sam układ, to pryszcz.

Reply to
Lukasz

Witam pewnie masz racje jakąś ten pomyśl jak wiele innych powędruje na półkę . J nie mam potrzeby się tym zajmować ale Łukasz jak już cos sensownego wymyślisz to daj znać . Może ktoś ma program do procesorów PCM futaby ? Marek S

Reply to
Marek S

Ok. Jak zacznie działać w komplecie :) Na razie na zestawie prototypowym na razie uruchomiłem tylko na jednym kanale. Właśnie strawiłem pierwsza płytkę docelowego układu.

A co do atmega32, to przywiązałem się do tego układu po prostu, polubiłem go.

Reply to
Lukasz

Dnia 04.02.2007 Lukasz snipped-for-privacy@poczta.onet.WYTNIJpl> napisał/a:

witam rzeczywiscie badanie sygnalu jest strasznie upierdliwe, nie wystarczy sama kontrola prawidlowej dlugosci impulsow czy odleglosci miedzy nimi, bo odbiornik przy wylaczonym nadajniku odbieral dosc czesto jakies smieci ktore sie kwalifikowaly niby jako dobre, z tego co sie bawilem to jak sie liczylo do 3 dobrych kolejnych ramek bylo lepiej, przy 4 przez caly dzien chodzilo ok do tego dochodzi to ze przy obsudze klawiatury czy lcd 10MHz procek sie obija totalnie, to tutaj przy rozdzialce 1000 czy 2000 krokow na zakres sterowania serwa (plus minus 1mili sekunda) wychodzi 1 czy 0,5 mikro sek a to jest malutko cykli :-(

Reply to
Karol

Potwierdzam. To jest własnie ten problem :) Poprawnośc impulsów sprawdzam w ten sposób, że liczę ilość cykli w ciągu sekundy. Jeśli < 25 lub > 100 popranwych, to odłączam serwa (trwa to pół sekundy).

Problemem jest jeszcze równoczesne trzymanie serw w zaprogramowanej pozycji tak, żeby nie drgały i równoczesne sprawdzanie, czy sygnał z nadajnika juz wrócił do normy. To jest dopiero sztuka. Spóźnienie, niedokładność sterowania rzędu kilkunastu taktów zegara już powoduje drganie serwa.

Przyznaję, że pierwotnie myślałem: phi! 16MHZ, toż zawrotna prędkość. A teraz liczę każdy takt zegara...:), a obliczenia wykonuję w czasie tej niecałej jednej milisekundy od podniesienia sygnału, do opuszczenia. Wtedy tylko mam "czas wolny".

Mimo, że w pracy siedze nad takimi układami, to przyznaję, że nie doceniłem problemu do końca :)

Reply to
Lukasz

Lukasz napisał(a):

Witam, z ciekawością obserwuję Twoje postępy a to dlatego, że sam mam ochotę zająć się czymś analogicznym. Podejrzewałem, że mogą powstać takie problemy, dlatego ja myślę o zastosowaniu dwóch procesorów - jeden do łapania sygnałów z serw i do ich generowania a drugi do obliczeń, bądź też puścić całe we/wy na przerwaniach. Bo komunikacja między tymi dwoma procesorami to byłoby góra kilkanaście bajtów na cykl (czyli 50 razy na sekundę), a więc nie powinna zabijać systemu. Na Atmelach się nie znam, ale pracuję z procesorami Cypress. To dość zgrabna architektura, na razie myślę o zrobieniu na nim takiego właśnie procesora komunikacyjnego. Na Cypressach dałoby się nawet zrobić całe we/wy na przewaniach, więc sprawa obliczeń nie byłaby tak restrykcyjna. Niestety cyprysy są dość słabe - tylko kilka MIPSów i max 2 KB RAM, ale czy na początek potrzeba więcej?

pozdrawiam

Remigiusz Żukowski

Reply to
Remigiusz Zukowski

Kruca bomba - mało casu.

Problem, jak napisał Karol, polega na tym, że np. sterując sygnałem serwa musisz opuścić zbocze sygnałowe w ściśle określonej chwili, z dokładnością do 1 mikrosekundy (przy 1024 krokach).

U mnie, przy 16MHz (16MIPSów) 1 mikrosekunda, to jest 16 taktów zegara. Robię to na przerwaniu zegarowym, więc jest dokładnie. Dopóki nie trzeba sprawdzać nadajnika - wszystko musi działać idealnie.

Jeśli np. w międzyczasie wyskoczy Ci jakiekolwiek przerwanie, to nie może być ono dłuższe, niż 16 taktów. A już samo wywołanie procedury przerwania zabiera już 6 taktów. Czyli masz max. 10 taktów wewnątrz przerwania, a to są raptem może 2 instrukcje. W praktyce moje (HS-50) serwo zaczyna drgać przy niedokładności rzędu 2-3 mikrosekund.

Tak więc przy kilku MIPS-ach może być mało czasu. Można robić inne czynności, ale tylko zaraz po podniesieniu zbocza jednego z serw. Zakładam, że mam wtedy pewny wolny czas ok. 0.5-1.0 milisekundy, kiedy wiem, że nic się nie powinno zdarzyć.

Na szczęście serwa są włączane sekwencyjnie, bo procek by nie wyrobił na zakrętach... :) I na całe szczęście protokół PWM serw przewiduje tą "przerwę" 1 msek, w której coś mozna zrobić pożytecznego. Albo uśpić procek na drzemkę, co by prądu nie marnował.

Itd. itp...

Reply to
Lukasz

PolyTech Forum 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.