Cześć.

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 czasowe
b) nie wiadomo kiedy przełaczyć na odbiór, tam jest tylko bodaj 3.5
znaku czasu na zmianę kierunku

Czy to jest faktycznie tak realizowane czy też obudowuje się to w jakiś
protokół wyższej warstwy budujący właściwe ramki?

Po poczytaniu internetów mam wrażenie że to jest faktycznie tak
prymitywnie realizowane. Ale może ktos mnie wyprowadziz błędu.

do góry

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 :-)

> b) nie wiadomo kiedy przełaczyć na odbiór, tam jest tylko bodaj 3.5
> znaku czasu na zmianę kierunku

Skoro przychodzi pakietami, to naturalne wyslac caly pakiet.

I chyba tylko jakies dlugie dane moga byc dziwnie podzielone,
czy jesli rzeczywiscie przechodzi przez caly Internet.

Ale ... widzialem na wifi dlugie opoznienia.

J.

do góry

On 28/12/2019 16:47, J.F. wrote:
> ethernet jest szybki, caly pakiet sie zmiesci w jednym znaku RS :-)

Internet już nie.

>> b) nie wiadomo kiedy przełaczyć na odbiór, tam jest tylko bodaj 3.5
>> znaku czasu na zmianę kierunku
> Skoro przychodzi pakietami, to naturalne wyslac caly pakiet.

Przychodzi strumieniem. O nieznanych punkach krojenia, w dodatku
niezależnych ani od nadawcy ani od odbiorcy. Nie wiadomo czy następny
znak nie dochodzi bo to już koniec czy następny nie dochodzi bo porno ma
QoS.

> I chyba tylko jakies dlugie dane moga byc dziwnie podzielone,
> czy jesli rzeczywiscie przechodzi przez caly Internet.
> Ale ... widzialem na wifi dlugie opoznienia.

Krojenie pakietów odbywa się nawet w domowym routerze do internetu.

Albo to jest jeszcze jedna z tych skrajnie dziadowskich "technologii" w
automatyce albo nie potrafie się doczytać jak to ma działać poprawnie.

do góry

On 28-Dec-19 17:16, heby wrote:
> Albo to jest jeszcze jedna z tych skrajnie dziadowskich "technologii" w
> automatyce albo nie potrafie się doczytać jak to ma działać poprawnie.

Pomysł z socat to faktycznie jest raczej cienki ale konkretnie dla
modbus - bo zgaduję, że o to pytasz - są rozmaite wynalazki
programistyczne (np. mbusd) albo sprzętowe (np.
https://www.aliexpress.com/item/32934899607.html), które realizują
konwersję protokołu modbus RTU <-> modbus TCP.

IMHO działa. A konkretnie dla sportu odpaliłem serwer openhab "w
internetach" i sterowałem nim oświetleniem domowym. Szału nie było ale
światło dało się zapalić i zgasić bez jakiegoś dramatycznego lagu ;-)

Piotrek

do góry

On 28/12/2019 19:47, Piotrek wrote:
> Pomysł z socat to faktycznie jest raczej cienki

Działa. Przy czym zawiera wszelkie problemy z protokołem TCP - a wiec
nieoczekiwane przerwy. W LANie raczej działa bez problemu, w internecie
po pietnastym przepakowaniu ramek już niekoniecznie.

> ale konkretnie dla
> modbus - bo zgaduję, że o to pytasz - są rozmaite wynalazki
> programistyczne (np. mbusd)

mbusd pełni rolę serwera i ma własny protokół (na ile własny a na ile
standardowy przemysłowo?), najpewniej odporny na problemy czasowe tcp.

> https://www.aliexpress.com/item/32934899607.html), które realizują
> konwersję protokołu modbus RTU <-> modbus TCP.

Dam radę zrobić na Pi.

> IMHO działa. A konkretnie dla sportu odpaliłem serwer openhab "w
> internetach" i sterowałem nim oświetleniem domowym. Szału nie było ale
> światło dało się zapalić i zgasić bez jakiegoś dramatycznego lagu ;-)

Ale tu nie o lagi chodzi, tylko o to że znacznikiem końca ramki modbus
jest brak znaku. I tak pechowo może być że w tcp ten brak znaku w
określonym czasie może przyjść randomicznie.

do góry

On 28.12.2019 20:06, heby wrote:

> Ale tu nie o lagi chodzi, tylko o to że znacznikiem końca ramki modbus
> jest brak znaku. I tak pechowo może być że w tcp ten brak znaku w
> określonym czasie może przyjść randomicznie.

No to zbierasz ramkę po rs aż przyjdzie koniec ramki, po czym ją
opakowujesz, przesyłasz po tcp. Po drugiej stronie odbierasz, sprawdzasz
czy cała i wysyłasz po rs.
Jak to sobie inaczej wyobrażasz?
Nie wiem jak w modbus, ale nie wszystkie urządzenia gadające normalnie
po rs485 dadzą się oszukać przejściówkami rs<>tcp, tcp<rs>, bo na
przykład oczekują odpowiedzi _natychmiast_ po zakończeniu transmisji.
Można to próbować obejść wysyłając lokalnie "powtórz" i następnie po
powtórzonej ramce wysłać już odpowiedź, która w między czasie nadeszła.

--
Mirek.

do góry

On 28/12/2019 21:24, Mirek wrote:
>> Ale tu nie o lagi chodzi, tylko o to że znacznikiem końca ramki modbus
>> jest brak znaku. I tak pechowo może być że w tcp ten brak znaku w
>> określonym czasie może przyjść randomicznie.
> No to zbierasz ramkę po rs aż przyjdzie koniec ramki, po czym ją
> opakowujesz, przesyłasz po tcp. Po drugiej stronie odbierasz, sprawdzasz
> czy cała i wysyłasz po rs.
> Jak to sobie inaczej wyobrażasz?

Jeśli nie opakujesz ramki w jakiś protokół (ze znacznikami końca i
początku) to nie da się tego osiągnąć bez jakiś problemów związanych ze
strumieniową formą protokołu TCP. Nie wiadomo kiedy ramka się kończy i
zaczyna następna, geniusze od modbusa uznali że przerwa w transmisji
wystarcza a w TCP nie ma żadnej gwarancji że przerwa przyjdzie tam gdzie
ją nadałeś z drugiej strony.

Ja pytam o to bo są tylko dwie opcje:

a) podobnie jak 99% populacji programistów, ludzie produkujący
konwertery RS485<->TCP nie ogarniają problemów z TCP i działa im przypadkowo

b) w przemyśle stosuje się jakieś protokoły opakowujace ramki modbus w
strumieniu, ale nie mogę ich namierzyć (mbusd ma jakiś sposob, ale czy
wyjatkowy czy standardowy?)

> Nie wiem jak w modbus, ale nie wszystkie urządzenia gadające normalnie
> po rs485 dadzą się oszukać przejściówkami rs<>tcp, tcp<rs>, bo na
> przykład oczekują odpowiedzi _natychmiast_ po zakończeniu transmisji.
> Można to próbować obejść wysyłając lokalnie "powtórz" i następnie po
> powtórzonej ramce wysłać już odpowiedź, która w między czasie nadeszła.

To jest jakiś inny problem, niezwiązany z moją wątpliwoscią co do TCP ;)

do góry

Dnia Sat, 28 Dec 2019 21:24:25 +0100, Mirek napisał(a):
> On 28.12.2019 20:06, heby wrote:
>> Ale tu nie o lagi chodzi, tylko o to że znacznikiem końca ramki modbus
>> jest brak znaku. I tak pechowo może być że w tcp ten brak znaku w
>> określonym czasie może przyjść randomicznie.
>
> No to zbierasz ramkę po rs aż przyjdzie koniec ramki, po czym ją
> opakowujesz, przesyłasz po tcp. Po drugiej stronie odbierasz, sprawdzasz
> czy cała i wysyłasz po rs.
> Jak to sobie inaczej wyobrażasz?
> Nie wiem jak w modbus, ale nie wszystkie urządzenia gadające normalnie
> po rs485 dadzą się oszukać przejściówkami rs<>tcp, tcp<rs>, bo na
> przykład oczekują odpowiedzi _natychmiast_ po zakończeniu transmisji.

To "natychmiast" to chyba symbolicznie, bo kazdy system komputerow ma
jakis tam czas reakcji.
Chyba, ze sprzetowe urzadzenie ... ale przeciez trzeba jeszcze kirunek
przelaczyc ...

J.

do góry

heby wrote:

> Cześć.
>
> 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 czasowe
> b) nie wiadomo kiedy przełaczyć na odbiór, tam jest tylko bodaj 3.5
> znaku czasu na zmianę kierunku
>
> Czy to jest faktycznie tak realizowane czy też obudowuje się to w jakiś
> protokół wyższej warstwy budujący właściwe ramki?
>
> Po poczytaniu internetów mam wrażenie że to jest faktycznie tak
> prymitywnie realizowane. Ale może ktos mnie wyprowadziz błędu.


Konwertery nic ie dodają.
W praktyce to działa; ramki modbus są któtsze niż ramki TCP i chyba nie są
za bardzo, ze względów wydajnościowych, siekane na mniejsze kawałki.

W ustawieniach takiego konwertera (o ile dobrze pamiętam) chyba jest tylko
wartość przerwy po jakiej ma wysłać pakiet, który przyjdzie z hosta po r485.

Ale istnieje jeszcze coś takiego jak ModbusTCP. I tam jest to w prosty
sposób obudowywane ale już bez crc właściwej dla modbusa.

jp



--
jp

www.flowservice.pl
www.flowsystem.pl

do góry

On 29/12/2019 15:15, jacek pozniak wrote:
> Konwertery nic ie dodają.
> W praktyce to działa; ramki modbus są któtsze niż ramki TCP i chyba nie są
> za bardzo, ze względów wydajnościowych, siekane na mniejsze kawałki.

Niestety to działa w dwie strony:

write(stream,"ala");
write(stream,"foo");

po drugiaj stronie może przyjść:

"alafoo"

"ala"
"foo"

albo "alaf" "oo" itd.

Ponadto nie ma czegoś takiego jak ramka tcp na poziomie aplikacji ;)
Jest strumień.

> W ustawieniach takiego konwertera (o ile dobrze pamiętam) chyba jest tylko
> wartość przerwy po jakiej ma wysłać pakiet, który przyjdzie z hosta po r485.

Czyli niestety miałem racje że to nastepna żałosna technologia :(

do góry