Witam ,
Niedawno temu ,był wątek na temat sterowania silnika do bramy .
Problem banalny , choć wystarczająco "wielowątkowy" aby spróbować
sformułować kilka podstawowych algorytmów , oraz rozwiązań sprzętowych
komplikujących lub też upraszczających realizację.

Zainteresowanym proponuję następującą zabawę :
a. Dowolną bramę obsłużymy na ATTiny 2313 ,z przynajmniej dwukrotnym zapasem mocy obliczeniowej i zasobów.
b. Poszukamy najwydajniejszych rozwiązań sprzętowych jako pierwszy etap
optymalizacji .
c. Wyznaczymy niezbędne "usługi" projektu i wyznaczymy ich algorytmy.
d. Znajdziemy optymalny sposób ich zapisu w C.
e. Pomijamy całą "pinologię" jako coś, co zainteresowani "skroją sobie na własną miarę"
f. Utworzona notacja obejmuje tylko dane/zmienne potrzebne do obsługi samych algorytmów.
g. Sterownik do "byle czego" zasilamy "byle czym" - stąd obsługa obejmuje obsługę sygnałów stykowych z histerezą,
a z uwagi na bliskość silnika i jego sterowania , pilnujemy tylko schludności zasilania procesora .

Na początek jako punkt wyjścia proponuję , w co najmniej jednym punkcie nadmiarowy schemat i algorytm.




Jeśli ktoś jest zainteresowany , zapraszam do "sporu o bramę" - powinno być "sporu w bramie " - ta forma ma już dluuugą tradycję
J.P.

Cieszę się że kolega jp_elek podjął taki ciekawy temat jak sterownik do bramy.
Wprawdzie popełniłem już kiedyś taki sterownik w asemblerze i ciekaw jestem rozwiązań w C.
Nie wspomnę już o zagadnieniach sterowania mocą silnika indukcyjnego 230V poruszanych już na forum.

_________________
sig off ;(

Ja tam za bardzo się nie znam, ale jak widzę sterowanie kierunków za pomocą dwóch odzielnych pinów na przekaźnikach to mi się zaraz zapala taka ogromna czerwona lampka a nad nią pytanie. Co by się stało gdyby przez przypadek wysterowąc dwa przekaźniki na raz. Niestety nie znam się na tyle na elektronice żeby zaproponować jakąś alternatywę , dlatego napiszę tylko tyle że tutaj ja osobiście poszedłbym w kierunku jakiegoś rozwiązania hardwarowego które by wykluczyło przypadkowe załączenie dwóch przekaźników na raz.

@Malutki_27 - właśnie od tego jest procesor żeby strzegł przed takimi przypadkami .

_________________
sig off ;(

O co on ma strzec skoro tym steruje Mi tam i tak się tutaj ogromna czerwona lampka świeci , a jak jeszcze pomyslę żę tam jest 230 V to już mi ciarki przechodzą

------------------------ [ Dodano po: 10 minutach ]

Oki Problem po kilku minutach sam się rozwiązał przecież wystarczy po stronie 230V zrobić odpowiednią kombinację w połączeniu styków i problem przestanie istnieć

Ano ,
Bardzo ważna uwaga malutki_27, może się zdarzyć bumm..
Zatem może nieco udoskonalona wersja , jest jednak ale..,
szukanie przekaźników z wieloma zestawami styków , nie jest ciekawym zajęciem , może więc
styki użyjemy raz do załączenia silnika , oraz drugi raz do blokady , a "podtrzymanie/potwierdzenie załączenia
przekaźnika na transoptorze - prąd diody "podobny" do prądu małego przekaźnika więc będzie ok.
Gdyby silnik był większy to jeszcze na kolejnych stycznikach powtórzymy taką samą blokadę ze styków pomocniczych stycznika.

oto propozycja lepszego schematu :


Pierwsza uwaga bardzo celna , szukajmy dalej...

ps. Tak niechcący zyskujemy -przy transoptorach izolację na dzień dobry min.4000 V oraz styki "oddalamy od niskiego napięcia procesora .

W zależności od silnika można to znacznie uprościć, sprzętowo jak i programowo- jeden przekaźnik załącza nam silnik, drugi ustala kierunek obrotów. Jak bym miał wykonywać taki napęd to silnik pozyskałbym z wiertarki lub innego podobnego elektronarzędzia- po pierwsze komutatorowe są łatwe do regulacji, po drugie mamy wstępną przekładnię oraz sprzęgło w zestawie.

Zwróciłbym też uwagę na brak możliwości wykrycia przeciążenia silnika w powyższym schemacie- a w zimie raz że opory mechaniki większe to do tego dochodzi jeszcze lód który może nam skutecznie zablokować bramę.

_________________
Klimatyzacja Przemyśl

Przecież mamy kontrolę obrotów - to wykryje nam zarówno blokadę silnika ,
jak też zbyt małe obroty..

Mi bardziej chodziło o coś takiego jak na schemacie

Siedzę w automatyce do bram więc powiem jak to jest w centralach profesjonalnych (tak to nazwijmy).
Jak kolega wyżej napisał, jeden przekaźnik włącza zasilanie ogólne a drugi zmienia kierunek obrotów, a do tego jest jeszcze triak który reguluje prędkość jak i siłę siłowników sterujących skrzydłami bramy.

Tak ,
Nie do końca rozumiem pomysł ze schematem Malutki_27 , jeśli np. X1 to zasilanie , a X2 to silnik to nic się nie zmieni, niezależnie od tego który przekaźnik
uruchomimy , chyba że silnik jest prądu stałego - ale to nie zdarza się - często, regulacja tak , ale po zdefiniowaniu silnika indukcyjny asynchroniczny , czy też
szeregowy -uniwersalny, o tym proponuję nieco później , po ustaleniu jakie zdarzenia musimy obsłużyć , i jakie algorytmy "zatwierdzimy" jako zadowalające ..

Rzeczywiście masz rację , podszedłem do tego jak do silnika prądu stałego

Co do zdarzeń no to według mnie taki sterownik powinien mieć:
- regulację obrotów silnika
- regulację mocy ale to raczej będzie współistniało automatycznie z regulacją obrotów
- kontrolę przeciążenia silnika , blokady silnika
- barierę przed przytrzaśnięciem ( chodzi o wykrywanie przeszkód przy otwarciu lub zamknięciu )
- sygnalizację pracy w postaci lapmy ostrzegawczej
- jakieś wyłączniki krańcowe by się przydały
- ewentualnie jakieś sterowanie ryglem dla bramy bądź furtki.

O takich rzeczach jak piloty czy też podłączenie do jakiejś "jenteligencji domu" wydaje mi się że nie ma co wspominać

Zgoda ,
to w pierwszej kolejności chciałbym nazwać , które wymogi są rzeczywiście potrzebne.
Wyłącznik krańcowe już zaproponowałem, sygnał Kolizja traktuję jako zarówno fotokomórka oraz "przytrzaśnięcie" , nie mam zdania - czy sygnalizacja otwierania jest użyteczna, chyba że jakieś nowe przepisy jej wymagają .
Rygle owszem , ale z oddzielnego wyjścia - do rozważenia
Odbiornik pilota i piloty - z reguły za kilkanaście złotych do kupienia,
robienie "radia" to chyba nieuzasadniony - niełatwy temat,
z punktu widzenia sterowania , niczego w sterowniku i tak nie zmieniają- dublują sygnały otwórz/zamknij/stop

Witam,
Po wstępnej dyskusji proponuję przyjąć poniższe założenia , aby tworzenie projektu nie trwało miesiącami :
- projekt wykonujemy , w postaci "modułów", którymi kolejno będziemy się zajmować od definicji po realizację-
- moduł musi być spójnym elementem - zarówno sprzęt jak też oprogramowanie, jego wykorzystanie , będzie albo
konieczne, albo opcjonalne ;

Schemat = ogólny , zawiera tylko niezbędne elementy , dodatkowe wyposażenie - jako opcja na oddzielnym schemacie

Oprogramowanie - podobnie , choć kolejność proponuję odwrócić - najpierw zbudować algorytm główny sterownika ,
chciałbym aby to była funkcja "main" w pliku main.c i wyrzucone z niej wszystko, co jest w istocie usługą przygotowującą dane, i tak:
- w osobnym pliku wszystkie funkcje czasówek
- w osobnym obsługa styków , sygnałów pomocniczych , ogólnie IO,
- w osobnym obsługa silnika -moment obrotowy, obroty itp.

// wszystkie potrzebne, a jeszcze nie stworzone funkcje deklarujemy jako void funkcja(void) z pustym ciałem{} funkcje nazywamy zgodnie ze schematem/grafem algorytmów i tylko tymczasowo
- do czasu ich sformułowania mają prawo obecności w pliku main.c, po nabraniu ciała - wynocha do swojego pliku //

ps. wiem ,że to może mało dydaktycznie , ale zapewnia po zdeklarowaniu głównego algorytmu - wyartykułowanie potrzeb, i tworzenie usług - które niejako
same się definiują przez nazwę i brakujące oprogramowanie zdarzeń.

Teraz proponuję dokonać ostatecznego osądu poniższego schematu - pamiętamy iż ma zapewnić sprzętową informację o stanie bramy
bez wnikania jeszcze w szczegóły czy kolizja to przecięcie wiązki fotokomórki , czy uderzenie w przeszkodę, czy naciśnięcie przycisku bezpieczeństwa,
czy silnik będzie taki czy inny , dwa przekaźniki wystarczą do każdego silnika, regulację prędkości dopuścimy dopiero, gdy będziemy mieć sterowanie
standardowej bramy - powiedzmy garażowej, lub co kto tam za najprostszą-bezpieczną uważa.






Po zaakceptowaniu schematu rozpoczynamy dyskusję nad algorytmem, wiedząc z góry iż funkcja zamknij załatwi wszystko ,
wraz z poproszeniem pieska aby od bramy się odsunął , - ciałem obdarzymy ją w stosownym momencie jak naszym zdaniem będzie na nie zasługiwała

Oto uzupełniony o ochronę przekaźników przed bumm.. algorytm sterowania bramą.
Założyłem , że zawsze da się uznać iż jeden z kierunków jest mniej kolizyjny ,
dlatego dla bramy otwórz/zamknij wybrałem priorytet otwieranie, dla góra / dół będzie to zapewne góra.


Oto schemat algorytmu :


Zapraszam do wytykania braków - i podejmowania prób zapisu algorytmu.

To może ja napiszę jeszcze coś od siebie.
- fotokomórki - zapobiegają zamknięciu bramy jak coś podczas zamykania pojawi się w ich barierze
- wyłączniki krańcowe nie są konieczne jeśli wyliczymy czas zamykania + czas dodatkowy (np centrala 452MPS)
- czujnik amperometryczny (przeciw zgnieceniowy) - nie wszystkie centrale do bram skrzydłowych posiadają, powinny posiadać wszystkie garażówki
- wejście STOP - obowiązkowe zabezpieczenie, rozłączenie wyłącza silniki centrali
- wyjście na lampę sygnalizacyjną - mają wszystkie centrale
- wyjście na elektrozamek - zwykle opcjionalne
- wejście na encoder - do zliczania impulsów i precyzyjnego sterowania otwieraniem/zamykaniem
- spowolnienia czyli regulacjia prędkości - zwykle na starcie i pod koniec zamykania/otwierania (nie jest równoznaczna z mocą)
- druga linia fotokomórek (opcjonalnie)
- wejście PP czyli tak zwane sterowanie KROK PO KROKU - wejście pełni taką funkcję jak sterowanie z pilota (zwykle są równoległe)
- ustawianie logiki pracy czyli AUTO, PÓŁAUTO, DEADMEN (obecny operator), ZESPÓŁ MIESZKANIOWY i kilka innych
- ? jak mi się przypomni to napiszę

Witam ,

Jak widać, temat nie okazał się nośny ... aby jednak zakończyć sensownie obietnicę złożoną na początku ..

Przygotowałem najprostszą wersję sterownika bramy , z komentarzami wszystkich
szczegółów , chyba łącznie z każdym przecinkiem .

- W miarę swoich możliwości , użyłem nieco innych od dotychczas prezentowanych sposobów
realizacji, podstawowych elementów programu .Znacznie na wyrost- niemal sztucznie , jednak podzieliłem
program na odrębne pliki, aby zapewnić maksymalną przejrzystość .

- Ponadto wyeksploatowałem preprocesor najbardziej jak potrafiłem aby ... sam kod był najbardziej jak
to możliwe "ludzki",zrozumiały "dla każdego"( dla mnie to sposób na unikanie błędów ,
przy pisaniu wiele razy tego samego - pierwszy raz zdarza się napisać poprawnie , drugi-może poprawnie, trzeci raz na pewno źle )

- użyłem wzgardzanego w innym wątku ( topic2939.html ) rejestru GPIOR0 na pohybel prześmiewcom
, za pogardę dla jego - rejestru - nieskazitelnej opinii i oczywistej WYŻSZOŚCI na mizerią "bandy 32"- która przecież jest -
ale jak potrzeba akurat jej nie ma !

- zaproponowałem bardzo szybką i skrajnie prostą , ale bardzo wydajną funkcję SIMPLE_DEBOUNCE , tam
nazwałem ją Set_Sta();(nie dość ,że prosta to jeszcze prostsza do modyfikacji)

- nieocenione usługi GPIORx użyłem również dla obsługi timer'ów programowych.

- program zorganizowałem tak , iż wszystkie dane są przygotowane w przerwaniu(ach), a pętla main jest
czysta jak łza , i równie prosta i banalna.

- w załączeniu schemat i graf programu obsługi sterownika bramy oraz komplet plików.

- temat sterownika bramy zamykam z oczywistych względów .

- Zapraszam do dyskusji , "Czy przystoi ? " tak wydziwiać w "C", a także jak - jeszcze bardziej
zmuszać "C" do " rozumienia " bardziej ludzkiego zapisu i nie wydziwiania ?" (To chyba oczywiste,iż
kolejna wersja Eclipse zadowoli się tym iż zechcemy wypowiedzieć co ma dla nas wykombinować w "C" ,
nie zaś zmuszać do wypisywania dziwolągów i jeszcze się czepiać, że za mało dziwolągowato piszemy ???) .

Graf algorytmu :


Schemat jako odniesienie do programu :


Plik main.c na zachętę :



kompletny programik :

taka mała pierwsza uwaga do kodu w C,

TCCR0A |= ((0<<COM0A1)|(0<<COM0A0)|(0<<COM0B1)|(0<<COM0B0)|(1<<WGM01)|(0<<WGM00));

tak się nie robi przesunięć zobacz tutaj:

post36313.html#p36313

bo jakbyś tam miał jedynki w tych bitach to po tej operacji by na dodatek zostały

------------------------ [ Dodano po: 13 minutach ]

aż się zaparłem i szukałem użycia GPIOR

SZOK ... no można - można oczywiście, że można i przede wszystkim nikt koledze nie broni a wręcz przeciwnie. Jak ktoś lubi tak się bawić ? - czemu nie

.... i znalazłem:



no ale takie korzyści to mnie jednak rozkładają na łopatki - tzn nie mam tu zamiaru prześmiewać kolegi broń boże, tylko tak patrzę sobie i myślę, że koledze jeszcze długo ten asembler tzn to asemblerowe podejście nie przejdzie. A tak z ciekawości skoro piszesz że korzystamy na wielkości kodu i szybkości działania to ile ? w porównaniu do czego ? - bo tak trzeba byłoby podejść do sprawy jakby się chciało pokazać korzyści Dokładnie to samo można zrobić na zwykłej zmiennej w RAM ... i co że nawet wyszłoby kilka cykli więcej ? co z tego ? program się zawiesi? przestanie działać? źle zacznie działać ?

nie nie nie ...

ale daję sobie głowę obciąć, że za jakiś czas kolega sam będzie na to patrzył z lekkim uśmiechem na te swoje przeliczenia i porównywania do asemblera na wyciskanie każdego cyklu zegara .... Musi minąć troszkę czasu zanim dotrze że C nie jest do tego

ale ja już widzę, że tak będzie z kolegą - bo co by dużo nie mówić - widać, że kolega programuje przede wszystkim NIE OD DZISIAJ ani OD WCZORAJ ... że doświadczenie jest i to spore - to widać nawet po takich początkowych bojach w C .... bo widać dobre algorytmiczne podejście ....

teraz tylko troszkę trzeba posiorbać C że tak powiem i samo przejdzie tzn to asemblerowanie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Co do wielkości kodu/ilości cykli ,
w wątku o GPIOR to Domanoid wskazał na tą notę aplikacyjną Atmela ,
zatem to jego zasługa , ja tylko pokażę interesujący fragment:

(ilość cykli dopisałem sam !!!, Atmel nie precyzuje , bo jak wiadomo zależy od konstrukcji kodu, podałem minimum i takie sobie rozrzutne , na szybko optymalizowane)




Tak naprawdę , o takie dyskusje mi chodzi , przecież widać iż jest cztery razy tyle miejsca ile potrzeba , i tak by się zmieściło,
raczej chodziło mi o taki projekt który nie zaabsorbuje uwagi wielkością, zrozumiały będzie prawie intuicyjnie , a uwaga dyskutantów
skupi się na metodach , w końcu wcześniej czy później , ale nie da się uniknąć styków, czasówek , transmisji , które w projekcie będą tylko
złem koniecznym, ale nieuniknionym , myślę iż wymiana myśli jak takie "zło" ukryć przed programem , który zupełnie nie dla styków itd.
piszemy jest ciekawa . Tak, zaczynam z "C" , ale tak jak asemblerowi , nie pozwoliłem sobą rządzić i jemu się podporządkować--
sam słusznie wytykałeś mi , że niby piszemy w asemblerze a tak naprawdę konstruujemy twory C-podobne, Basic'o- podobne itd.
Dlaczego , miałbym C , objąć szczególną ochroną przed np. " uczynić go bardziej ludzkim " ???

------------------------ [ Dodano po: 37 minutach ]

ps. spróbowałem kompilacji z najniższym poziomem optymalizacji ,
i jeszcze się mieści ale.. ino ino - to ponad 1600 bytów , może jednak
rozwaga w popuszczaniu cugli ma sens ??

Dyskusja miała dotyczyć bramy, nie tego ile bajtów będzie miał program

Po drugie: listingi są na tyle krótkie że mogłeś śmiało wstawić je w SYNTAX- nie każdy ma ochotę od razu importować do eclipse i sprawdzać co tam napisałeś.

_________________
Klimatyzacja Przemyśl

Hej ,
Dyskusja o bramie - nie przyjęła się jak widzisz ,
a zamiarem było "zrobić bramę" wspólnie ,tak aby wytykać słabości ,
wspólnie optymalizować , przemycić przy okazji , "różne podejścia do tego samego".
Założyłem iż projekt jest tak prosty iż nikt się w dyskusji nie pogubi , a brama byłaby bonusem.

Dzięki za radę z , "opublikowaniem kodu " bezpośrednio w poście , jeśli dyskusja "złapie " to pewnie skorzystam .,
problematyczne dla mnie były jednak komentarze na których mi zależało,a jak widać jest ich znacznie więcej niż samego kodu.
J.P.

Wracając do tematu bramy, jako że sam jestem szczegółowy jeżeli chodzi o bezpieczeństwo i niezawodność.
Brakuje mi jakiegoś nadrzędnego "procesu" który by pilnował czy aby ktoś lub coś nie znajduje się w zasięgu bramy, przy jej zamykaniu czy otwieraniu.
Czy np. nasze auto wzięte na 8letni kredyt nie zostanie zmasakrowane bramą, lub co gorsza, dziecko napędzane chęcią przywitania rodziciela nie wybiegnie na spotkanie z poruszającą się bramą. Lub co gorsza nie włoży rąk czy innych części ciała w mechanizm, bo pewnych jego elementów nie jesteśmy przecież w stanie zabudować dla 100% bezpieczeństwa.
I dla mnie jako ojca to by było kluczowe przy sterowaniu bramy, czyli priorytet całkowity jakiekolwiek przerwanie "strefy bezpieczeństwa" to bezwzględne zatrzymanie bramy i odcięcie zasilania od wszelkich mechanizmów z koniecznością ich ręcznego zresetowania gdzieś na drugim końcu domu .
Wiem, może przesadzam, ale szczerze mówiąc nie chciał bym być odpowiedzialny za jakikolwiek wypadek tylko z tego względu że ktoś jest zbyt leniwy by zrobić zabezpieczenie czy z niego korzystać.

To taka luźna dygresja w temacie bramy.

Witam , mimo , iż temat bramy jakby zamknąłem..

Potwierdzam , sam to bez końca "wałkuję" przy wielu różnych sytuacjach .
Otóż " legalnie - pożal się Boże "czyste ręce" mamy, jeśli we wspomnianej sytuacji odłączymy zasilanie " .

Życie jednak ma w nosie przepisy , tworzy oczywiste sytuacje , gdzie takie podejście
jest mocno szkodliwe - przecież oczywiste iż w takiej sytuacji należało by przede wszystkim
rozsprzęglić silnik od napędu - jak to zrobić nie łamiąc przepisów( bez wyłączania zasilania , co najmniej opóźnionego ) ,
a co jeśli monter uznał za niepotrzebną fatygę wyważenie bramy i po zwolnieniu sprzęgła
zamiast uwolnić docisk , brama "runie" w tą czy inną stronę.,
Jedna z przedstawionych wersji , próbuje "okpić" użytkownika , zatrzymując bramę przy pierwszej kolizji , jeśli zaś
zostanie " powtórzona" ( kasowanie kolizji następuje niejako niezależnie od nas przez duże ujemne przyśpieszenie,
w chwili zatrzymania napędu ) - to wtedy "niezwłocznie" załącza przeciwny kierunek . Rozwiązanie jak każde inne
czasem się sprawdzi , czasem niestety nie .
Dzięki za posta , to jest właśnie dyskusja, którą nazwę pożądanym sporem o bramę, - "sporem w bramie"

ps. niestety nie mam wiele uznania dla legalistów - wolę świadomie współtworzących , nowe prawa !!! - uwaga karalne !!

Wiesz, ja tam bram nie montuje, domu nie mam, ale chciałem zwrócić uwagę na problem, co w obecnej w naszym i nie tylko naszym kraju, tandeciarstwie niestety bezpieczeństwo schodzi na dalszy plan.

Jeżeli sam fakt zamykania bramy z "obecnym" samochodem w jej świetle można by jeszcze jakoś przeboleć - dupa jesteś gdzie stajesz - to kurtyna dla dziecka, czy zwierzęcia powinna być bezwzględna.

Niestety w wielu projektach DYI bram w ogóle nie jest to brane pod uwagę, a szkoda.......

No , tak źle nie jest , tutaj mamy sygnał Kolizja ,i jego obsługujemy ,
niestety w przewrotności swojej, z ochrony wyłączył bym koty- ale to inny temat
i nie całkiem poważny.

Mam dwa, coś o tym wiem ......

Ja mam aż trzy ale jakbym miał mieć w ogóle bramę, która przez nieuwagę zrobiłaby mi np z jednego kota dwa (brrrr) - i miałbym ich mieć już 4 to nie nie .... dziękuję

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No Mirku jestem tego samego zdania , ale spróbuj tylko na innym forum odezwać się, że brak zabezpieczeń w sterowniku to cię zjedzą .
Po prostu znając trochę mechanikę i bezwładność zaczął bym projektowanie od założeń czy brama się zatrzyma w właściwym momencie, a nie czy zamknie się 5sekund szybciej .

@mirekk36
co do kotów , bydlę to jak wiadomo jest specjalnym przypadkiem stworzenia ,
jeśli tak, to i poprzeczka na przeżycie kota - powinna być Specjalnego typu,
a nuż owo bydlę pokazało by jak jeszcze można ratować się ( nas oczywiście nadal interesowało by
jak ratować wszystkich oprócz kota ) z "opresji bramy " ???

Ja tam do żadnych zwierząt nic nie mam, no może po za najgorszym możliwym zwierzęciem, czyli człowiekiem .

Jak już wspominałem, rozważenie bezwładności bramy nie jest takie skomplikowane, w końcu jeżeli robimy sami, wiemy ile i jakie materiału użyliśmy, co za problem zważyć, jeżeli zamówiona to też w dokumentacji będzie.
Potem to już kwestia czy wahadłowa, dwu czy jedno skrzydła, czy przesuwna, dobrze zaprojektowana z przeciw wagami to się powinna sama zamknąć po lekkim tyknięciu paluszkiem .
Sprzęgło na silniku też nie problem....wystarczy kawałek gumy, forma zależnie od przeniesienia napędu itp. wszystko zależy od konkretnego rozwiązania.
Wolno zamykająca się brama krzywdy nie zrobi, jeżeli stanie w momencie naruszenia stref bezpieczeństwa.
Przecież nie rozmawiamy o bramach do NORAD, ani bramkach zwalnianych na wielkiej pardubickiej gdzie bramka się ma otwierać szybko i bez opóźnień.

PS. Problemem z "inżynierami" projektującymi bramy jest taki, że słabo się rozeznają w tematyce rozkładu mas, bezwładności czy nawet trwałości użytych materiałów .......nie mówię tutaj o każdym, ale niestety sporo projektów woła o pomstę do nieba.

Co do kotów... podobno mają 7 żyć, więc za którymś razem się w końcu nauczą żeby w zamykającą się bramę nie wchodzić

Według mnie powinna być ustawiana opcja obsługi kolizji, czy ma tylko zatrzymywać bramę czy zatrzymać i rozpocząć ruch przeciwny (otwieranie).
Ja sam jestem zwolennikiem tej drugiej opcji ale oczywiście wszystko zależy od okoliczności wystąpienia zdarzenia.

Ciekawą opcją dodatkową jest również automatyczne zamykanie, po otworzeniu bramy nic się nie dzieje do momentu przecięcia bariery, po jej przecięciu zaczyna być odliczany czas np. 2 minuty i jeżeli nie nastąpi kolejne przecięcie wiązki (reset czasu), brama automatycznie się zamyka.
Opcję tę można powiązać z przyciskiem otwierania, np. standardowo jest ona włączona ale gdy w czasie otwierania zostanie ponownie użyty przycisk 'otwórz', opcja automatycznego zamykania zostaje zdezaktywowana (potrzebujemy zostawić otwartą bramę na jakiś czas).

Co do kodu programu to na razie rozumiem komentarze , no może trochę więcej, ale ogólnie jak dla mnie jest w porządku.

_________________
sig off ;(