dziwny problem

Potrzebuję takie dziwne coś...może podpowiecie.

Otóż - MCU ma włączać lub wyłączać przekaźnik. Ale nie może to być zrobione po prostu w ten sposób, że jakiś port steruje tym przekaźnikiem, włączając go na określony czas.

Dlaczego ? Ano dlatego, że chodzi o bezpieczeństwo. W razie np. awarii samego MCU, albo chociażby zawieszenia MCU mogłoby się zdarzyć, że ten port mógłby pozostać włączony dłużej niż trzeba. A to się nie ma prawa wydarzyć.

Obecnie jest to rozwiązane w taki sposób, że w układzie są dwa MCU. Jeden nadzoruje drugi i jeżeli wykryje, że ten drugi coś robi nie tak - odłącza ten przekaźnik (oba muszą go uruchomić, żeby się włączył). Ale jest to nieco upierdliwe - trzeba oprogramować oba MCU itp.

Zatem - chciałbym pozostawić jeden MCU. Ale - zamiast sterować jednym portem - zastosować np. 3 linie. Aby przekaźnik został włączony - musi pojawić się określona sekwencja na tych 3 liniach. Znaczy - musi ona się tam pojawiać cały czas, z określonym okresem.

Jeżeli ta sekwencja zostanie zakłócona jakkolwiek - przekaźnik zostaje wyłączony i dodatkowo zostaje wygenerowany sygnał resetujący MCU.

Od strony programu, sekwencja będzie generowana równocześnie w kilku miejscach programu - osobno dla każdej "linii" - aby jak najmniejsze było ryzyko, że program się "zapętli", a sekwencja nadal jest generowana poprawnie.

Pytanie jest - jak możliwie prosto zrobić ten zewnętrzny układ ? No bo zastosowanie w jego roli MCU jest bez sensu w stosunku do obecnego rozwiązania.

Układ musi być jak widać sekwencyjny, ale też z "pomiarem czasu", żeby jakieś zmiany poprawnego czasu było wykrywane. Czyli chyba żadne proste układy logiczne się nie nadadzą, zwłaszcza że nie chcę dodawać x elementów.

Użycie jakichś wyrafinowanych układów typu FPGA czy nawet układów logicznych o "dużej mocy" też jest jakby nie na miejscu - bo to będzie w sumie bardziej kłopotliwe niż drugi MCU.

Może podpowiecie, jakie układy programowalne będą "w sam raz" ? Cena do kilkunastu zł ma sens. Obudowa SMD. Może być jednokrotnie programowalne, czy wielokrotnie - nie ważne.

A może jest jakiś wynalazek, który do czegoś takiego służy (wątpię) ?

PS; oczywiście oprogramowanie wykorzystuje watchdogi. Ale to niestety nie jest zabezpieczenie przed nietypowymi zachowaniami programu - nie zapewnia bezpieczeństwa. Jednak kiedy program się wykrzaczy w "idle", to pół biedy. Przekaźnik musi być w 100% włączany przy "pełnej świadomości" programu - stąd konieczność takiego zabezpieczenia.

Reply to
sundayman
Loading thread data ...

Niby dlaczego? Watchdog strzela resetem, przekaźnik jest wyłączony w procedurze resetu i nie włączy się do aż oprogramowanie się nie odnajdzie.

Jesli zapętli się z popychaniem watchdoga to przecież to samo co zapętlenie z popychaniem magicznego scalaka. Ryzyko takie samo.

Reply to
Sebastian Biały

Użytkownik "sundayman" napisał w wiadomości grup dyskusyjnych:o9mvt3$tsf$ snipped-for-privacy@node1.news.atman.pl...

Jakis port I2C/SPI ... sterujacy 74123.

I programowo musisz wachlowac pinem portu, bo inaczej to po chwili 123 przestanie sie wyzwalac.

J.

Reply to
J.F.

W dniu 07.03.2017 o 19:58, sundayman pisze:

CPLD?

Reply to
Jakub Rakus

Chyba że upali się port (ale tak samo może się upalić i w innym scalaku), pytanie jakiego rodzaju zakłócenia to ma wytrzymać.

Poza tym - czy styki przekaźnika mogą się skleić? Jeśli tak to może warto dać drugi przekaźnik, szeregowo, rozłączany po tym pierwszym i załączany przed nim...

A może jakiś układ, który wywali bezpiecznik, jak przekaźnik będzie za długo włączony?

Chyba że soft w ogóle nie wystartuje. Ale (przynajmniej w AVR-ach) reset powoduje przejście wyjścia w stan wysokiej impedancji - elektronika musi to podciągnąć pod jakiś właściwy stan i zinterpretować jako "przekaźnik wyłączony" (bez podciągnięcia zakłócenia mogłyby wyzwalać przekaźnik).

Reply to
Adam Wysocki

Gorzej jak oba się zawieszą, bo zakłócenie pójdzie na oba.

Z jedną linią wydaje się proste - układ różniczkujący RC.

A może jakiś expander I2C i za nim układ różniczkujący? Procek musiałby machać pinem expandera, czyli wykonać dosyć złożoną sekwencję.

A może NE555? Procesor musi resetować timer co jakiś czas, żeby utrzymać stan umożliwiający włączenie przekaźnika drugim portem...

Coś mi mówi, że zapewnienie 100% bezpieczeństwa elektronicznie może nie wystarczyć. Masz (Ty lub osoba odpowiedzialna) ubezpieczenie na wypadek skutków zbyt długiego włączenia przekaźnika? Może warto o tym pomyśleć, szczególnie jeśli straty mogą być nie tylko finansowe...

Generalnie poczytałbym o zasadach MISRA C i skupił się na tym, żeby program (przynajmniej część odpowiedzialna za logikę przekaźnika) był jak najprostszy. Im bardziej coś przekombinowane, tym więcej miejsca na pomyłki...

Reply to
Adam Wysocki

Jeśli spore to pozostaje być może zrobienie na 74123 lub całkowicie analogowo.

Tylko że spore zakłucenia propagują sie na logikę. Może trzeba wziąć uC przeznaczony do pracy w cieższych warunkach (np PIC zamiast ARV).

Tak czy inaczej jesli watchdogowi ufać nie można to chyba nic sie nie da zrobić od strony cpu a wymyslanie magicznych sekwencji zakończy się tym że procesor wygeneruje randomiczne szumy na pinach po awarii i będa pasować ...

Mam piec weglowy z podejnikiem węgla sterowany z jednego przekaźnika. Kilkukrotnie sterownik szlag trafił. Albo nie łączy albo skleja. Jak sklei to po kilkudziesieciu minutach mam pożar. Autor software i hardware nie przejmował się tym jednak jak widać za bardzo :D Ot, tranzystor na port i reszta dnia wolne.

Dokładnie tak załatwiłem ten sterownik. Między nim a silnikiem podajnika jest układ czasowy, ktory bezlitośnie odcina silnik dwoma przekaźnikami jak przekroczy limit jednorazowej pracy. Być może uratowało mi to dom.

Każdy cpu ma stabilny stan resetu. Mimo to osoboście wstawiłbym nie dośc że dwa przekaźniki szeregowo to jeszcze dodatkowy cpu z asercją czasową lub jakąs inną zależna od sytuacji. Jego programuje się *jeden* raz na caly proces developingu software w głownym cpu. Program tego pomocnika bedzie miał 10 linijek.

Reply to
Sebastian Biały

W dniu 2017-03-07 o 19:58, sundayman pisze:

Zewnętrzny watchdog powinien tu wystarczyć. Może być ich kilka jak chcesz bardzo się zabezpieczyć - każdy odpalany inną linią.

Czyli potrzebujesz sterować przekaźnikiem z obu stron - watchdogi trzymają jedną stronę, a sam procek drugą.

Bramka AND/NAND/OR/NOR z odpowiednią liczbą wejść. A jeżeli chcesz to zapamiętać, no to dajesz klasyczny przerzutnik (D albo JK, bo one się do tego nadają). A w sumie to zamiast bramek możesz poszukać czegoś z otwartym kolektorem.

A co to są zmiany poprawnego czasu? Jak to sobie wyobrażasz? Że watchdog zadziała ale nie zadziała? To tak nie może być z zasady. Czy chcesz mierzyć czas co jaki wystawiasz impulsy do watchdoga? No to nie jest jakieś wielkie wyzwanie o ile masz dość liczników.

Bo pewnie masz watchdogi programowe? A to trzeba dać hardware. Jak najprostszy.

Piszesz o jakimś niebezpieczeństwie. Może podchodzisz do tematu z niewłaściwej strony? Jedna z zasad zabezpieczeń zapalników bomb lotniczych mówi, że zabezpieczenia muszą wykorzystywać różne zjawiska fizyczne (opór powietrza, bezwładność itd). Nie wiem z jakiego rodzaju niebezpieczeństwem masz do czynienia, ale może po prostu potrzebujesz analogową/dodatkową/zewnętrzną kontrolę stanu? Np. ustawiasz "normalną" czułość układu regulacji na jakimś poziomie (przy poprawnym sterowaniu), a po przekroczeniu parametru (ale jeszcze na poziomie bezpiecznym) dodatkowy układ rozłącza np zasilanie przekaźnika (od drugiej strony) itd. i robi reset procka. Może też jest możliwość pomiaru jakiegoś innego parametru?

Pozdrawiam

DD

Reply to
Dariusz Dorochowicz

W dniu 07.03.2017 o 19:58, sundayman pisze:

Odetnij składową stałą sygnału sterującego podobnie jak to się robi w podwajaczach napięcia. Żeby trzymać włączony przekaźnik uC będzie musiał machać pinem. Jak się zawiesi na 1, to po jakimś czasie przekaźnik się wyłączy.

formatting link

Reply to
Zbych

No to proponuję sterować przekaźnikiem przez tranzystor z prostownikiem diodowym na wejściu, a z MCU sprzężyć go pojemnościowo. Dowolne stany stałe na portach się przez kondensator nie przeniosą, więc w przypadku zawieszenia układ się automatycznie wyłączy.

Przebieg sterujący generuj sobie SPI albo UARTem, jeśli ma być naprawdę failsafe, to na pollingu, a nie przerwaniach. Jak nie zdążysz, to Ci się bajt skończy transmitować i przekaźnik znów się wyłączy.

Czyli wychodzi kondensator, dioda, rezystor bramkowy i MOSFET.

Pozdrawiam, Piotr

Reply to
Piotr Wyderski

W dniu 2017-03-07 o 21:50, Dariusz Dorochowicz pisze:

A jeszcze jeden pomysł przyszedł mi do głowy - wyzwalanie watchdoga przez przerzutnik D. Sterujesz wejściem D i CLK przerzutnika, a jego wyjście dopiero na watchdoga. JK się mniej do tego nadaje, bo przy którymś stanie na wejściach robi za dwójkę liczącą, a na D jak nie będziesz zmieniał stanu wejścia to nie będzie zmian stanu na wyjściu.

Pozdrawiam

DD

Reply to
Dariusz Dorochowicz

Słuszna koncepcja, serwisantom też trzeba dać zarobić.

Co do tematu, klepanie pinem z wypełnieniem 50% + filtr RC + komparator okienkowy obejmujący 2,5V +-0,5V.

CPLD to raczej armata na muchy, toż dla 3 pinów wystarczy 2 układy.

OT. W mikrofalówkach są 2 włączniki, w przypadku awarii drzwiczek jest zwarcie i leci bezpiecznik.

Reply to
V.L.Pinkley

Zbiorczo odpowiadam :

Jednak nie takie samo. Watchodog użyty jest w obrębie całego programu. Wyobraź sobie teraz, że program w trakcie obsługi tego najważniejszego procesu zostanie niespodziewanie "przerzucony w inne miejsce. Nadal będzie się wykonywał, być może nawet poprawnie. A watchdog będzie nadal pracować. To niestety zjawisko, które może realnie wystąpić, a nawet miałem taki przypadek.

Opis, który zrobiłem jest pewnym uproszczeniem. W rzeczywistości po pierwsze jest "drugie odcięcie", ponieważ przekaźnik jest za układem tranzystorowym, który po pierwsze spełnia rolę PWM, a po drugie właśnie odcina sygnał.

A styki przekaźnika są "monitorowane" - jest sygnał zwrotny do MCU.

Sam 74123 to rozwiązanie nie nadające się do kontroli kilki linii wyzwalających, zwłaszcza jeżeli mają działać sekwencyjnie. Poza tym - co do rozwiązań analogowych - układ może działać w bardzo szerokim zakresie temperatur. I pojawiają się problemy z np. charakterystykami kondensatorów. Wolałbym tego uniknąć.

No to jest jakieś minimum absolutne, ale - może się zdarzyć, że program zapętli się jakoś "w tym machaniu" i wówczas dupa. To jest imo słabsze rozwiązanie niż istniejące (bo przy 2 MCU mamy jednak 2 razy mniejsze ryzyko co najmniej).

To jest problem firmy, która te urzadzenia montuje, i za nie odpowiada. Ja robię, co mogę od strony technicznej. Tylko i aż tyle :)

Chodzi mi o to, żeby układ "nadzorujący" wymagał nie tylko określonej sekwencji, ale też określonych "czasów" tych sekwencji. Krótko mówiąc - żeby wykrył ewentualne opóźnienia/przyspieszenia.

Temat jest ściśle tajny niestety, i nie mogę pisać o szczegółach, bo zaraz potem musiałbym was wszystkich zabić :) No a ile bym się musiał najeździć w tym celu ??

OK - niebezpieczeństwo może (nie musi) powstać, jeżeli zadany czas uruchomienie tego przekaźnika zostanie przekroczony. Przy czym - uwaga - czas ten nie jest stały. Tj. może być zmieniany przez obsługę co jakiś czas.

Obecnie jest on zapamiętywany w obu MCU, i w trakcie pracy odmierzanie czasu odbywa się w obu.

Podstawowe ryzyko, to właśnie nieprzewidziane zachowanie programu, na skutek występujących bardzo silnych zakłóceń EM, czy to na zasilaniu. (oczywiście, elektronika posiada ekrany EM).

Praktyka pokazała jednak, że na uderzający w okolicy piorun nie ma siły, i MCU potrafi zrobić coś, co wydaje się niewykonalne - np. zmienić ustawienia w jakimś rejestrze, co powoduje że sam program działa nadal poprawnie, tylko nie zupełnie w tym otoczeniu MCU co trzeba :)

Dlatego chodzi mi o to, żeby wykonanie "uruchomienia" i - co ważniejsze

- jego dalsze utrzymanie w działaniu - nie mogło się odbyć po jakimś przypadkowym wejściu do procedury.

Oczywiście mogę pozostać przy obecnym rozwiązaniu - świat się nie zawali, choć miałem nadzieję na uproszczenie (w sensie braku konieczności programowania 2 MCU).

Dodatkowym plusem byłoby zmniejszenie ryzyka awarii urządzenia, spowodowanego tym, że MCU jednak są bardziej podatne na to niż np. układy logiczne.

Taka awaria nie skutkuje niebezpieczeństwem o którym tu mowa, ale - po prostu może wyłączyć urządzenie. Choć jak dotąd nie pojawiło się to więcej niż kilka razy na kilkaset urządzeń.

A z dwojga złego - lepiej, żeby sterownik się wysypał całkiem, niż gdyby miał źle działać.

__________________________

Co propozycji dotyczących MCU - używam atmeli. Nie wiem, czy są potwierdzone analizy, że inne MCU są bezpieczniejsze ?

W oprogramowaniu są stosowane rozwiązania zwiększające bezpieczeństwo - np. przechowywanie zmiennych w wielu komórkach pamięci i kontrola, czy wszystkie są zgodne itp. Oczywiście także kontrola CRC pamięci programu po restarcie, czy też właśnie okresowe restartowanie systemu co godzina.

To są rzeczy, które istotnie zwiększyły niezawodność - jak dotąd był jeden niebezpieczny przypadek (jeszcze w czasie kiedy nie stosowałem rozwiązania z dwoma MCU). No, ale wolę dmuchać na zimne - teoretycznie istnieje ryzyko dla zdrowia czy życia ludzie - żartów więc nie ma.

Reply to
sundayman

Dnia Tue, 07 Mar 2017 13:47:22 -0800, V.L.Pinkley napisał(a):

A nie lepiej prosty step up? tranzystorem steruje noga proca, jeden tranzystor, jedna cewka, dioda, i przekaźnik na 12V, może jeszcze kondensator do tego i bezpiecznik. Jak prawidłowo działa uc to generuje prostokąt, wtedy napięcie jest podbijane i przekaźnik się załącza, w innym przypadku czy to 0 czy 1, przetwornica nie działa.

Reply to
Bo(o)t Manager

Przekombinowujesz. Poprawność działania programu uzyskuje się przede wszystkim poprzez odpowiednie testy. Takoż samo uzyskuje się poprawność (klasę) działania urządzenia jako całości w określonych warunkach. Jeśli używasz zwrotu "nietypowe działanie programu" w kontekscie własnych urządzeń produkcyjnych (w rozumieniu końcowych) to od razu sugeruje, że nie masz wdrożonych odpowiednich testów oprogramowania i puszczasz urządzenia na żywioł. Konsekwencją tego jest później kombinowanie i rozwiązywanie nieistniejących problemów.

Reply to
Marek

przekaźnika.

Każdy przekažnik ma ścisle odkreślony. min. prąd styków, który jest wymagany do ich prawidłowej konserwacji (prawidłowego załączania), stawiam źle dobrany przekaźnik., wręcz po co w ogóle przekaźnik.

Reply to
Marek

bezpieczniejsze ?

Oczywiście, przede wszytkim do trudnych warunków używa się wersji I (industrial), które m.in. mają szerszą temp. stosowania. Każdy model PICa jest dostępny w wersji I, nie wiem czy atmele tak mają. Oczywiście nie wspinając o odpowiednmi projekcie pcb.

Reply to
Marek

Źle zaprojektowany program, nieprawidlowa implementacja obsługi watchdoga. Wyczuwam bascom albo inne tego typu pseudo języki...

j.w.

Reply to
Marek

Z ciekawości: a zrobiłeś matematyczną analizę że drugi MCU zmniejsza ryzyko? Bo może być dokładnie odwrotnie: dwa MCU to dwa razy większa szansa awarii plus problemy dodatkowe...

Reply to
slawek

prostownikiem

Problem numer zero: przekaźnik może nie rozłączyć, np. stopione zestyki.

IMHO sensowne byłoby połączenie szeregowe przekaźnika i czegoś półprzewodnikowe (tranzystor?). To półprzewodnikowe po generalnym kaboom powinno ładnie się psuć do przerwy w obwodzie.

Z totalnie głupich (tzn. analogowych) trików: bezpiecznik bimetaliczny. W każdym czajniku elektrycznym coś takiego jest.

Reply to
slawek

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.