eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikadziwny problemRe: dziwny problem
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.chmurka.net!.POSTED.xt.v.chmurka.n
    et!not-for-mail
    From: g...@s...invalid (Adam Wysocki)
    Newsgroups: pl.misc.elektronika
    Subject: Re: dziwny problem
    Date: Wed, 8 Mar 2017 15:13:38 +0000 (UTC)
    Organization: news.chmurka.net
    Message-ID: <oTdarrguI7vhNv8%gof@news.chmurka.net>
    References: <o9mvt3$tsf$1@node1.news.atman.pl>
    <58bf1d88$0$662$65785112@news.neostrada.pl>
    <o9nh2p$ndo$1@news.icm.edu.pl>
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: 8bit
    Injection-Date: Wed, 8 Mar 2017 15:13:38 +0000 (UTC)
    Injection-Info: news.chmurka.net; posting-account="gof";
    posting-host="xt.v.chmurka.net:172.24.44.4"; logging-data="28035";
    mail-complaints-to="abuse-news.(at).chmurka.net"
    User-Agent: tin/2.3.3-20160327 ("Kinloch") (UNIX) (Linux/3.16.0-4-amd64 (x86_64))
    DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=chmurka.net; s=news;
    t=1488986018; bh=QkaKfiLUBF0MSna/XVVxX5SmT4g=;
    h=From:Subject:Newsgroups:References:Message-ID:Cancel-Lock:
    User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding;
    b=df2JPmgvoxIxSz0dsaZjUmVwZE7F17qAi8XG64BUJ7CkBYhqn9ciLLLmXvywSquGa
    HLJmTDa2dqcJibIal/wLkQtDKFDqZYs7OUz8Ni5wJ+B6z0zpfgDBB9KLeig6Rznulv
    TEEsDpg852n96UAN3oMZ8u8C8Sx3sPucPtSzyuJs=zyuJs=
    Cancel-Lock: sha1:HAqT9UCzvffEWkbq1LirTBdawe4=
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:714249
    [ ukryj nagłówki ]

    sundayman <s...@p...onet.pl> wrote:

    >> Jesli zapętli się z popychaniem watchdoga to przecież to samo co > >
    >> zapętlenie z popychaniem magicznego scalaka. Ryzyko takie samo." w
    >
    > 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.

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

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

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

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

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

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

    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.

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

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

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

    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.

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

    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.

    --
    http://www.chmurka.net/

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: