dziwny problem

użytkownik Bo(o)t Manager napisał:

Jak jest logiczna "1" wtedy prąd płynie przez klucz. Odporne na zwis są pompy ładunkowe, tylko z tych małej mocy przekaźnika nie zasilisz.

Dnia Wed, 08 Mar 2017 03:41:36 -0800, V.L.Pinkley napisał(a):

I po to w układzie jest bezpiecznik. Ewentualnie ogranicznik prądowy, no ale to trochę komplikuje układ.

W dniu 2017-03-07 o 19:58, sundayman pisze: > Potrzebuję takie dziwne coś...może podpowiecie. >

a może po prostu jakieś atiny i potem jeszcze ne555? proste i śmieszne pieniądze. atiny (lub podobne) zbiera do kupy sterowanie z linii, wystawia wyzwolenie na ne555. i ten na na jakiś czas załączy przekaźnik (przez tranzystor czy nawet jakieś opto). A czy przekaźnik ma działać też określony czas z góry czy to może się zmieniać?

No właśnie... coś mi mówi, że nie tędy droga. Niech MCU odpala przekaźnik tak, jak ma to robić, a nad brakiem katastrofy czuwa coś zewnętrznego, niekoniecznie nawet po stronie cewki przekaźnika.

No tak, nie pomyślał że coś się może stać z przekaźnikiem. Może w ogóle od softu była inna osoba, która nie zna się na elektronice.

Nie masz żadnej informacji o tym, czy i jak często odcina? Może warto dorzucić jeszcze jeden układ czasowy, który zrobi zwarcie kolejnym przekaźnikiem, gdy te dwa też się skleją? I wtedy bezpiecznik załatwi resztę.

Hmm, może CPU z asercją czasową, a może NE555 lub inny RC...

Miałeś tak na skutek błędu w sofcie, czy coś przestawiło rejestr PC?

Ok, tylko jak MCU wyłączy przekaźnik, a sygnał zwrotny będzie taki, że nie wyłączył, to co wtedy zrobi?

Hmm, charakterystyki są znane, urządzenie można przetestować potem w szerszym zakresie temperatur niż ten, w którym ma działać.

Ok, tyle dobrze że nie Ty odpowiadasz :) Chociaż jak będzie trup, to i tak zacznie się szukanie winnego, no i sama świadomość. Chyba że ryzyko jest "tylko" finansowe.

Jest jakieś zabezpieczenie przed zrobieniem literówki przez obsługę?

Ciężko będzie zabezpieczyć procesor. Zabezpieczyłbym przekaźnik. Niech układ czasowy, osobny, sprawdza czas działania przekaźnika i jeśli ten czas jest przekroczony, to robi jakąś czynność (wszczyna alarm, odcina drugi przekaźnik, zwiera zasilanie, ...).

W tym układzie nie dawałbym żadnej skomplikowanej logiki ani procesora.

To zdecydowanie. Ukrywanie błędów zawsze się mści, potem coś działa nie tak, jak zaplanowałeś, i nie masz pojęcia dlaczego. Wszystko, co piszę, a co jest trochę bardziej skomplikowane, ma kontrolę wewnętrznego stanu.

Półprzewodniki mają tendencję do uszkadzania się na zwarcie...

Tak, to zdecydowanie. Coś, o czym już ktoś wspomniał, czyli testowanie zjawiska fizycznego. Jeśli przekaźnik zasila piec - testować temperaturę. Jeśli zasila silnik, który coś przesuwa - zamontować wyłączniki krańcowe. Itd. Nie zawsze się da.

Nie ma ona sensu bo sterownik ma jeszcze jeden debilny błąd: jesli wlaczyc podawanie ręczne i "zapomnisz" to sterownik podaje do pieca wegiel cały czas nie patrząc na temperaturę. Innymi słowy można na własne życzenie spalić dom. Ponieważ obserwowanie jak kupka wegla w retorcie podnosi się o 1cm na minute jest mało fascynujące to nie jeden raz odchodziłem od pieca by po 15 minutach przypomnieć sobie o nim. Zazwyczaj jak juz bulgotał.

Efektem czego zabezpieczenie działa *dość* czesto i tutaj pretensje mozna mieć wyłącznie do głupiego programisty który wciska węgiel do pieca widząc na nim 90 stopni. Natomaist jesli chcesz wiedzieć ile bylo awarii od kiedy działa zabezpieczenie - do tej pory dwie. W tym jedna fatalna (sklejenie) i jedna mniej fatalna (kłopoty z rozłaczeniem i załączeniem, ale rozpinał za każdym razem).

Sterownik od dawna zmieniłbym na własny, ale nie mam odpowiedniego zbioru pieczątek i certyfikatów niezbednych od odszkodowania jak-by-co.

Na marginesie: miałem w ręku sterownik za coś koło 1kzł. W środku ... przekaźnik na silniku podejnika. W zasadzie taki sam jak u mnie. Tylko bardziej fancy-look.

Raczej dwa się nie skleją. One praktycznie nie rozłączają pod obciążeniem. Miał być jeszcze optotriak, ale sobie darowałem. Myślę że te dwa przekaźniki wystraczą, tym bardziej że zabezpieczenie "dla rozruszania styków" raz na jakiś czas rozpina silnik przed czasem wiec zakładam że nie skleją się też z powodu starości czy innej dyfuzji.

Można i analogowo, ale coś czuje że jesli ten kawałek hadrawe ma na pewno coś rozłaczyć to punktów rozłaczenia musi być więcej i raczej steorwanych z osobnych algorytmów. Jeden sterujący drugi jako asercja.

no i bardzo dobrze.

więc tak naprawdę, chcesz zastąpić MCU-nadzorce, równoważnym rozwiązaniem. jaki to ma być czas? Bo jeśli sekundy, i to z małą precyzją, zastosuj jakiś układ czasowy, na ne555 który po każdym załączeniu przekaźnika zacznie odliczać czas, i po zadanym czasie wyłączy przekaźnik, niezależnie od tego czy MCU zrobił to czy nie. tylko że budowa takiego układu ma sens, jeśli sztuk będzie dużo. jeśli to jednostkowe rozwiązanie - ja bym pozostawił 2 MCU. ewentualnie dwa różne MCU.

ToMasz

Nie, chodzi o coś innego. Program może np. w wyniku glitcha na zasilaniu zmienić wartośc rejestru w gdzie jest ilośc cykli. Z 5 na miliard. I powiedzmy że trzyma przekaźnik przez miliard sekund. W tym czasie prawidłowo popycha watchdoga. Tego nie da się łatwo wykryć w runtime.

To czego potrzeba to niezalezne asercje w osobnym kontrolerze. Ten kontroler realizuje takie rzeczy jak sprawdza jak długo jest właczony, czy była prawidłowa sekwencja właczenia, czy jest czwartek bo w czwartek nie wolno itd.

To robi układ sprawdzający asercje. Jako osobny kontroler.

Wykryje to i wiele innych nielegalnych stanów bądź sekwencji.

Urban legends :D Sądząc po niezrozumiałej popularności 8051 w sterownikach bram prawdopodobnie to byłby najlepszy wybór pod względem pieczątek.

Takie problemy mają mistrzowie od sterowników bram. One są czasem tak silne że moga przekroić tira na pół (no dobra, ale człowieka moga dośc niefajnie zdeformować). Wymagane jest bezpieczeństwo. Realizuje się je, jesli dobrze widziałem na kilku przykładach, poprzez modlitwę i głebokie przekonanie o słuszności kodu. W zasadzie w środku sieci jakiś przemysłowy stary uC i troche elementów biernych. W bardziej wypasionych sa jakieś pomiary mocy silnika, ale jak silnik jest za duzy to tego nie robią jak widzę bo to ciężka sprawa. Kiepsko to wygląda a podobno przechodzi cośtam rygorystycznego gdzieśtam (co pewno oznacza TUV).

Układu z dwoma uC nie widziałem jeszcze. Widac jak sie sprzedaje pcb za

5kE to każdy cent się liczy.

Może wypytaj najpierw jakie zabawne ograniczenia i wymogi są w dziedzinie w której to robisz. Swego czasu nie wolno było stosować sterowników do czegośtam (u Niemców) na triakach, dopuszczalne były tylko przekaźniki. Zmienili to kilka lat temu, ale było. Zaś w medycynie były i chyba nadal są znacznie wyższe wymogi np. izolacji.

Przy wyjątkowo nieszczęśliwym zbiegu okoliczności mogłyby być ofiary. Bardzo mało prawdopodobne - ale...

To jest zmiana via menu oprogramowania - oczywiście nie da się ustawić źle. A nawet złe (maksymalne) ustawienie nie jest problemem wielkim. Problem może być wtedy, kiedy urządzenie zostanie załączone, i się nie odłączy. Ten prawidłowy zakres czasów pracy to jakieś 10-60 sek. Jak będzie pracować 2 minuty też z Bogiem sprawa. Ale gdyby godzinę, to już może być kłopot...

I tutaj trafiasz w sedno. Dziś w nocy wymyśliłem chyba rozwiązanie. Otóż - niech "na zewnątrz" MCU będzie licznik. Do jego zapisania niezbędne jest użycie określonego "hasła", albo numeru układu - powiedzmy - jakaś magistrala szeregowa. Żeby nie było możliwe ustawienie i odpalenie tego licznika przypadkowo.

Sam licznik sprzętowo ograniczony do max. dopuszczalnego czasu.

Czyli :

1) MCU zapisuje wymagany czas 2) odpala odliczanie w dół 3) sam MCU również odlicza czas

Jeżeli wszystko jest OK, i MCU prawidłowo odliczy czas - zatrzyma zewnętrzny licznik.

Jeżeli zaś ten zewnętrzny timer dojdzie "do zera" - znaczy MCU jest w krzakach, wtedy reset, telefon na policję itp itd.

Oczywiście timer hardwareowy zrobiony tak, żeby MCU mógł przetestować jego działanie.

Piotrun, jebnąwszy w okolicy kilkudziesięciu metrów, za pomocą impulsu EM zmienił w MCU jakiś bit w rejestrze włączającym podciąganie rezystorów na wejściach, wyłączając je.

Co spowodowało dziwne stany na tych wejściach. Wystarczyło wyłączyć i włączyć urządzenie, żeby wszystko wróciło do normy. Żadnego sprzętowego uszkodzenia. Ot - jakiś tam bit się przestawił.

I nigdy bym nie wpadł na to, gdyby program nie miał funkcji rejestracji zdarzeń - ich analiza doprowadziła do takiego wniosku.

Oczywiście, to było w czasie, kiedy jeszcze sądziłem, że MOŻNA nie dać prawdziwego rezystorka podciągającego, tylko polegać na tym w MCU, a także kiedy w programie nie zastosowałem okresowego przywracania wszystkich istotnych dla działania rejestrów.

Czyli w czasie, zanim naczytałem się o prawidłowym programowaniu MCU do pracy w środowisku przemysłowym :) Dziś (tfu tfu) już nie występują właściwie żadne problemy - no ale w ramach modyfikacji i racjonalizacji chciałbym właśnie coś tam może uprościć czy poprawić.

Tego się prosto nie da zrobić, bo to co "leci" przez ten przekaźnik, to jest zasilanie silnika , z użyciem PWM oczywiście regulacja jest real-imte, czyli zmienna w czasie, zależna od wielu czynników.

Zatem i realna moc dostarczana na "wyjściu" jest zmienna.

Dnia Tue, 7 Mar 2017 21:38:05 +0100, Sebastian Biały napisał(a):

Ciekawe co jest napisane w instrukcji obsługi pieca bądź podajnika i co w razie pożaru miałby potem do powiedzenia prokurator...

Nawet w 100% poprawnie napisany program, z wszelkimi "sztuczkami" w rodzaju wielokrotnych kontroli danych, wypełnianiem pustych miejsc nopami itp. nie jest odporny na sytuację, w której pod wpływem zewnętrznego oddziaływania EM nastąpi "przestawienie" wskaźnika programu, i zacznie sobie działać "nie wiadomo skąd". No bo jeżeli EM może "przełączyć" bity w jakimś rejestrze to dlaczego nie w tym ?

Tak - jest ekstremalnie małe prawdopodobienstwo że tak się stanie. Ale wolę je wziąć pod uwagę. Niestety, nie jest możliwe zastosowanie takich zabezpieczeń , które będą w stanie zaekranować MCU w 100%. A może inaczej - może i by się dało, stosując jakieś stalowe skrzynie, itp. Ale - z różnych powodów firma, które to instaluje - nie robi tego, bo byłoby by zbyt upierdliwe.

Ja zaś wolę pogłówkować, dla własnego ew. świętego spokoju - zrobić tyle, ile można.

Cały diwajs pracuje w terenie - i najgroźniejszym przypadkiem, z którym się zetknąłem było wspomniane wcześniej "przestawienie" rejestru w MCU w czasie jebnięcia pioruna w odległości kilkudziesięciu metrów.

Urządzenia - takie jakie są - mają atest odpowiedniego instytutu : i gitara. Wszyscy są zadowoleni. Założenia specyfikacji są spełnione - wystarczy.

Ale mnie historia z tym piorunem ( ze 3 lata temu chyba to było...) nauczyła jednak, że nie ma tak, że "zabezpieczeń jest za dużo". Oczywiście w ramach ekonomicznego sensu, realnego zagrożenia itp. Ale - wróg nie spi ! Jak to się mawiało w PRL...

___________

Podsumowując - dziękuję za uwagi, bo w sumie mnie to naprowadziło na koncepcją, którą opisałem :

zrobić hardwareowy, programowany, z odpowiednim zabezpieczeniem - znaczy wymagający podania określonego "czegoś" dla zaprogramowania - zewnętrzenego timera, który sam z siebie nie będzie w stanie przekroczyć limitu czasu.

Oczywiście, mógłby to zrobić, ale to by wymagało już wielokrotnego, aktywnego udziału MCU.

W dniu 2017-03-08 o 20:58, sundayman pisze:

OK, ale w końcu dostajesz jakąś wartość fizyczną (ciśnienie, przesunięcie czy co tam jeszcze) która może spowodować zagrożenie - nie masz jej pomiaru?

Pozdrawiam

DD

Nie robiłem. Nawet nie bardzo sobie wyobrażam, czy i jak można by to policzyć, żeby miało sens... Poza jakimś efektownym wykresem w stylu ministra Morawieckiego :)

Jak masz pomysł jak - to chętnie się dowiem.

Ale ok - mamy dwa MCU, i żeby wykonać "działanie" oba muszą zgodnie współpracować. Przed "uaktywnieniem przekaźnika" każdy sprawdza, czy "kolega jest przytomny i odpowiada z sensem" - no to imo ryzyko, że coś pójdzie nie tak, jest mniejsze.

Nie dość, że musiałyby się wykrzaczyć oba MCU, to jeszcze dodatkowo oba tak, żaden nie odpali własnego watchoga. Bo jeżeli jeden z nich się zrestartuje niespodziewanie - a drugi pracuje, to zostanie do zauważone i koniec pieśni.

Nie chce mi się teraz wdawać w rozległą dyskusję na temat możliwych konfiguracji "awaryjnych" - oczywiście, nawet przy 3 MCU będzie ryzyko wystąpienia takiego układu, że coś się wydarzy. No ale jednak nie bez powodu stosuje się takie rozwiązania w kosmosie, że się multiplikuje układy (a co, czerpmy wzorce z lepszych :)

Jak dotąd nie było żadnego takiego przypadku "awaryjnego". Jedyny problem, jaki był z powodu użycia dwu MCU był w prototypie, w którym - ja głupi - użyłem w "mniejszym" MCU zamiast porządnego kwarca w zegarze, wewnętrznego oscylatora. Dla oszczędności 2 zł... Oczywiście bez przyjrzenia się dataszitowi w temacie...

Wszystko działało świetnie aż do testów w -20 st. Wtedy MCU1 przestał nagle widzieć MCU2 (komunikują się po RSie_ - rozjechały im się zegary. Efekt był więc taki, że główny MCU zauważył brak mniejszego, uznał że awaria i "please call service kurwa !".

Ni chuja :) Ten silnik napędza cosik, co jak za długo pracuje (dużo za długo) , może w dość odległej konsekwencji spowodować wypadeczek. Nie musi. Może - jeżeli się zbiegnie parę wyjątkowo pechowych czynników. To nawet od pogody może zależeć...

Oczywiście, w ślad za pracą silnika zmieniają się w układzie różne tam parametry - ale one same w sobie nic nie znaczą. Czyli nie ma przełożenia - jakiś parametr = problem.

Ponieważ problemem może być zbyt długa POPRAWNA praca całego systemu. Nie zaś jakieś przekroczenie jakiegoś parametru.

Nie wiem jaki dać analogiczny przykład...

Na piorun w pobliżu i znienacka siły nie ma. To jest skrajny przypadek. Tradycja jest taka, że jeszcze się nie spotykałem z opinią użytkownika, który by miał pretensję do instalatora (czy autora) sprzętu, który poddał się piorunowi. Wszyscy kiwają głowami ze zrozumienien podczas wymiany na nowy. A jeśli lecą jakieś urwy to w kierunku pioruna a nie instalatora. Przed czymś takim zabezpieczenie to dobra polisa a nie mieszanie szpachli łokciem i kombinowanie jak połączyć 3 mcu z nieklejącym się przekaznikiem.