eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaMultiplekser/sniffer/arbiter modbusRe: Multiplekser/sniffer/arbiter modbus
  • X-Received: by 2002:a25:d911:0:b0:b78:45fd:5f01 with SMTP id
    q17-20020a25d911000000b00b7845fd5f01mr1677503ybg.7.1680774977330; Thu, 06
    Apr 2023 02:56:17 -0700 (PDT)
    X-Received: by 2002:a25:d911:0:b0:b78:45fd:5f01 with SMTP id
    q17-20020a25d911000000b00b7845fd5f01mr1677503ybg.7.1680774977330; Thu, 06
    Apr 2023 02:56:17 -0700 (PDT)
    Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!2.eu.feeder.erj
    e.net!feeder.erje.net!news.uzoreto.com!peer03.ams4!peer.am4.highwinds-media.com
    !peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.googl
    e.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-fo
    r-mail
    Newsgroups: pl.misc.elektronika
    Date: Thu, 6 Apr 2023 02:56:17 -0700 (PDT)
    In-Reply-To: <u0m327$a4hi$1@dont-email.me>
    Injection-Info: google-groups.googlegroups.com; posting-host=84.10.46.130;
    posting-account=fcN60AoAAACGnErMsW3A8rTO2UKkGJEn
    NNTP-Posting-Host: 84.10.46.130
    References: <u0jesg$3rbf4$1@dont-email.me>
    <4...@g...com>
    <u0kfa6$513$1@dont-email.me>
    <a...@g...com>
    <u0lsao$95g4$1@dont-email.me>
    <c...@g...com>
    <u0m327$a4hi$1@dont-email.me>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <d...@g...com>
    Subject: Re: Multiplekser/sniffer/arbiter modbus
    From: Dawid Rutkowski <d...@w...pl>
    Injection-Date: Thu, 06 Apr 2023 09:56:17 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    X-Received-Bytes: 3237
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:779570
    [ ukryj nagłówki ]

    czwartek, 6 kwietnia 2023 o 11:23:24 UTC+2 heby napisał(a):

    > > Multi-master na jednej magistrali dałby radę po prostu z komputerem.
    > Ale jest trudniejszy, bo wymaga sniffingu i odrobiny modlitwy jeśli
    > jednak pojawi się ramka urządzenia, które wysłało ją dla beki wcześniej
    > niż przewidziałem.

    Stąd moje rozważania, czy urządzenie X ma taką funkcjonalność, że:
    a) sprawdza czy magistrala jest wolna przed rozpoczęciem wysyłania
    i jednocześnie
    b) słucha wysyłanych przez siebie pakietów, by sprawdzić, czy nic się
    w czasie nadawania nie wcięło i nie pokaszaniło komunikatu
    czy też może
    c) po prostu wysyła na pałę.

    > Interesuje mnie arbiter "rozcinający" połaczenie, jako podstawowa forma
    > tego urządzenia. To rozwiązuje sporo problemów elegancko, kosztem
    > zwiększenia czasu odpowiedzi w momencie "konfliktu".

    Oraz groźby całkowitego padu komunikacji między X a Y w przypadku padu arbitra.
    Oczywiście komputer włączony jako drugi master w multi-master na jednej
    magistrali też może komunikację pokaszanić, ale tylko wtedy, gdy zacznie
    wysyłać bełkot albo padnie w czasie, gdy TXE jest załączone (no na to
    można dać attiny żeby pilnował max. czasu jednego nadawania).

    Ogólne pytanie, co się stanie, jak X przestanie widzieć się z Y - i vice versa?
    Zapewne nie jest to reaktor jądrowy, ale kłopoty mogą się pojawić.

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: