eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaStandardy w automatyce domowejRe: Standardy w automatyce domowej
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erj
    e.net!feeder.erje.net!news2.arglkargh.de!news.mixmin.net!newsreader4.netcologne
    .de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am
    s4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!
    unt-exc-02.news.neostrada.pl!unt-spo-a-02.news.neostrada.pl!news.neostrada.pl.P
    OSTED!not-for-mail
    From: "J.F" <j...@p...onet.pl>
    Subject: Re: Standardy w automatyce domowej
    Newsgroups: pl.misc.elektronika
    User-Agent: 40tude_Dialog/2.0.15.1
    MIME-Version: 1.0
    Content-Type: text/plain; charset="utf-8"
    Content-Transfer-Encoding: 8bit
    References: <62fe06c9$0$488$65785112@news.neostrada.pl> <tdl434$vvqg$1@dont-email.me>
    <a...@n...neostrada.pl>
    <tdl756$10mfc$1@dont-email.me>
    <62fe3bbe$0$552$65785112@news.neostrada.pl>
    <tdlfth$127uf$1@dont-email.me>
    <62fe615b$0$556$65785112@news.neostrada.pl>
    <tdlrr7$1420k$1@dont-email.me>
    <62fe8f85$0$483$65785112@news.neostrada.pl>
    <tdm9ch$15l12$1@dont-email.me>
    <a...@n...neostrada.pl>
    <tdohec$1j14l$1@dont-email.me> <tdvrjr$8ag$1$PiotrGalka@news.chmurka.net>
    Date: Mon, 22 Aug 2022 14:32:46 +0200
    Message-ID: <dahuqdhqys0w$.s79cv6g97dtw$.dlg@40tude.net>
    Lines: 74
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 83.4.178.88
    X-Trace: 1661171566 unt-rea-a-02.news.neostrada.pl 472 83.4.178.88:62907
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 4837
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:773885
    [ ukryj nagłówki ]

    On Mon, 22 Aug 2022 14:08:26 +0200, Piotr Gałka wrote:
    > W dniu 2022-08-19 o 19:31, heby pisze:
    >> Natychmiastowa. Jestem uczolony na responsywność, dlatego to dla mnie
    >> krytyczne.
    >
    > Skojarzenie z responsywność. Nie całkiem na temat, ale jestem akurat
    > wściekły i jak sobie ponarzekam to może mi ulży :)
    >
    > Na RS485 od zawsze (czyli okolice 1995) działamy tak, że jak ktoś się
    > chce odezwać to się odzywa.

    Co zaraz powoduje problemy pod tytulem kolizje.
    Wykrywacie?

    > W ten sposób np. sygnał z tampera, że ktoś zerwał urządzenie ze ściany
    > zostanie przesłany praktycznie natychmiast. Atakujący nie zdąży przeciąć
    > kabla co skutkowało by informacją 'urządzenie nie odpowiada' zamiast
    > 'zostało zerwane ze ściany'. Według mnie prawidłowa informacja ma swoją
    > wartość.
    >
    > Miesiąc temu, ktoś kto od nas bierze sprzęt do realizacji instalacji ze
    > swoim oprogramowaniem przekazał nam, że zamawiający wpisał w wymagania
    > spełnienie normy PN-EN IEC 60839-11-5:2020. Opisuje ona 'Otwarty
    > protokół urządzenia nadzorowanego' w systemach kontroli dostępu. Nie
    > wiedzieliśmy, że to już jest ujęte w normę.
    >
    > Mam tę normę od 2 tygodni i ... szok i totalna załamka. Urządzenia nie
    > mogą się odezwać nie pytane - czyli ciągłe przeglądanie. Na odpowiedź
    > mają 200ms, ale zalecane jest aby zdążyły odpowiedzieć w 3ms.

    Przy niewielkiej ilosci szybkich urzadzen - moze to nie problem.
    Bedą odpytywane co poł sekundy ...

    > Kolega był kiedyś z kimś na obiekcie, gdzie po każdym zbliżeniu karty do
    > czytnika czekali ze 2..3 s aż drzwi się otworzą. I ten gość traktował to
    > jako normę. Dla mnie niewyobrażalne. Według mnie wypracowanie decyzji o
    > otwarciu drzwi nie powinno zajmować więcej niż 50 (no góra 100) ms.

    Komputery coraz szybsze, a Windows coraz wolniejszy :-)

    Rozumiem, ze to twoje zyczenie, ale jak czytnik ma sprawdzic gdzies
    "na serwerze", serwer sprawdzic "w bazie danych", to czas rosnie :-(

    > Dopuszczamy do 50 urządzeń na szynie. Przeglądanie może zająć trochę
    > czasu szczególnie jak urządzenia (obce) na serio potraktują te 200ms.
    > Wygląda na to, że albo wypadniemy z rynku, albo się dopasujemy i wkrótce
    > nasz system zacznie działać tak jak kolega tego wtedy doświadczył.

    > Driver RS485 odbierając bierze 0,3mA, nadając jakieś 40mA (rezystory
    > terminalowe). Cały świat kombinuje jak by tu zaoszczędzić energię.
    > Wprowadza się limity na moc stand-by. A tu nagle się okazuje, że
    > wszystkie szyny RS485 wszystkich systemów kontroli dostępu mają zużywać
    > według moich szacunków przeciętnie około 300 razy więcej energii niż
    > faktycznie potrzebują jednocześnie tracąc responsywność.

    > Do tej pory sądziłem, że nie ma głupich norm.

    Dorobicie "koncentrator szyn", bedzie 10 urzadzen na szynie i 5 szyn,
    podniesiecie predkosc - to sie okaze, nadajnik wiekszosc czasu jednak
    nie pracuje.

    A norma ... no coz, moze miala cos innego na celu.
    Np wspolny protokół, zeby można było urządzenia mieszać, brak kolizji,
    brak programowania w sensie - brak adresu "serwera". Choc mozna by
    dac jakis staly adres np 1 czy jakis brodcastowy "do wszystkich
    serwerow/kontrolerow".

    Byc moze tez przy okazji znika problem zajetosci kontrolera, choc
    odbior portu szeregowego i tak na przerwaniach przeciez ...

    A warstwa fizyczna jest tam podana?
    Bo moze i tak na ethernet przeszli :-)

    J.

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: