Szukam prostego układu do kontroli sekwencji sygnałów w przekaźniku z MCU

Wed Mar 08, 2017 7:32 pm   

On 2017-03-08 00:51, sundayman wrote:

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

Wed Mar 08, 2017 8:48 pm   

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.

Wed Mar 08, 2017 8:55 pm   

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ć.

Wed Mar 08, 2017 8:58 pm   

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.

Wed Mar 08, 2017 9:03 pm   

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...
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066

Wed Mar 08, 2017 9:21 pm   

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.

Wed Mar 08, 2017 9:27 pm   

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

Wed Mar 08, 2017 9:49 pm   

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 !".

Wed Mar 08, 2017 9:55 pm   

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

Wed Mar 08, 2017 9:57 pm   

On Wed, 8 Mar 2017 20:55:04 +0100, sundayman
<sundayman@poczta.onet.pl> wrote:

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.

--
Marek

Wed Mar 08, 2017 10:10 pm   

On 2017-03-08 21:03, badworm wrote:

a) przekaźniki moga się sklejać
b) zawór gazowy może popuszczać
c) c.o. może się utleniać
d) woda może być mokra

Nic nie napisali. Przecież wiadomo. A prokurator ma wnikać w sklejanie
przekaźników czy błedy w sofcie? Weź nie żartuj, sprawdzi pieczątki i tyle.

U mnie jest tylko taki problem że intensywnie uzywam pieca rownież w
lecie (grzeje basen) więc przekaźnik ma jakieś 3x szybsze zuzycie. Za
pierwszym razem jak się popsuł wymieniłem na identyczny. Potem na
lepszy. Czekam co dalej. Pozostał być może jakiś softstart do silnika
może ale nie wiem czy pomoże na żywotnośc silnika bo rozpinanie to chyba
zawsze łuk pociągnie.

Licze na to że w końcu to oleje i kupie PC.

Wed Mar 08, 2017 10:25 pm   

I w tym przypadku nikt nie miał pretensji do mnie.
Odpowiedzialność spada na firmę instalującą i nadzorującą te systemy
(mój sterownik to tylko drobny, choć ważny element).

Zresztą nic wielkiego się nie stało - musiała przyjechać ekipa,
posprzątać bałagan i tyle :)

Ja mogę tylko postarać się zrobić "co w naszej, wicie, mocy".

Wed Mar 08, 2017 10:31 pm   

W dniu 2017-03-08 o 21:55, sundayman pisze:

OK, jasne. No, może nie do końca, ale OK.
No to nie zostaje niż innego jak parę zewnętrznych watchdogów odpalanych
z różnych miejsc w programie. Plus na wszelki wypadek jeden na samym
przekaźniku, ale to jako dodatkowy - ostateczny, chociaż też nie
całkiem, bo wystarczy że na chwilę będzie przerwa no i załączenie z
powrotem.

Pozdrawiam

DD

Thu Mar 09, 2017 12:06 am   

Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:o9ps0h$3fq$1@node2.news.atman.pl...

"wieczny przekażnik"
www.elportal.pl/pdf/k07/19_12g.pdf


--
pozdr

Tomasz

tck(at)top.net.pl

Thu Mar 09, 2017 8:40 am   

slawek wrote:


Można się pozbyć przekaźnika i sterować silnikiem bezpośrednio
za pomocą wzmacniacza magnetycznego, choćby najprostszego, np.
z dwóch transformatorków sieciowych.

https://youtu.be/lB3HBoKPbOQ?t=322

Nie będzie ani problemu zwartych styków (z braku styków),
ani padu na zwarcie...

Pozdrawiam, Piotr