Użytkownik "marfi" napisał w wiadomości grup
dyskusyjnych:5e09ef8c$0$503$6...@n...neostrada.
pl...
Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
> Dnia Sat, 28 Dec 2019 00:32:17 +0100, heby napisał(a):
>>> Sporo programów ma opcje komunikacji z RS485 przez TCP.
>>> Czy ktoś może mi powiedzieć jak to działa w praktyce?
>>
>>> Wyobrażam sobie najtrywialniejszy przypadek, czyli przekierowanie
>>> strumienia TCP do portu RS485, wprost, bez żadnego analizowania
>>> bajtów
>>> (np. socat).
>>
>>> Ale to ma wady:
>>> a) pakiety TCP mogą być pocięte i posklejane, bajty przychodzą z
>>> opóźnieniami, dziurami a RS485 ma ścisłe zależności czasow
>
>> ethernet jest szybki, caly pakiet sie zmiesci w jednym znaku RS :-)

>Abstrahując od warstwy fizycznej która może pozwala tylko na 9600
>bodów?

Wlasnie dlatego - nawet jak interfejs zgromadzi cala dluga ramke z RS
i przesle jednym pakietem, to czas transmisji tego pakietu przez
ethernet bedzie porownywalny z czasem jednego znaku przez RS.

Gorzej, jak sie ktos uprze podkrecic RS np na ~1M ...

Chociaz ... tak scenariusz - program na pececie wysyla dluga ramke, po
czym spodziewa sie dosc szybko odpowiedzi z urzadzenia, moze nawet
dosc szybko pierwszego bajtu.

Tymczasem socket/TCP szybko powie programowi ze dane wyslane, i one
szybko przedostana sie do interfejsu, po czym on bedzie dlugo
transmitowal po RS, a program uzna, ze urzadzenie nie odpowiedzialo w
terminie.
Ale pecetowe programy juz sie chyba przyzwyczaily, ze transmisja nawet
po prawdziwym RS jest asynchroniczna i moze trwac dlugo.


J.