NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak wygląda praktyczne działanie konwerterów TCP/IP na RS485?
heby
Guest
Guest
Sat Dec 28, 2019 12:32 am
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.
J.F.
Guest
Guest
Sat Dec 28, 2019 4:47 pm
Dnia Sat, 28 Dec 2019 00:32:17 +0100, heby napisał(a):
Quote:
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
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 :-)
Quote:
b) nie wiadomo kiedy przełaczyć na odbiór, tam jest tylko bodaj 3.5
znaku czasu na zmianę kierunku
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.
heby
Guest
Guest
Sat Dec 28, 2019 5:16 pm
On 28/12/2019 16:47, J.F. wrote:
Quote:
ethernet jest szybki, caly pakiet sie zmiesci w jednym znaku RS 
Internet już nie.
Quote:
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.
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.
Quote:
I chyba tylko jakies dlugie dane moga byc dziwnie podzielone,
czy jesli rzeczywiscie przechodzi przez caly Internet.
Ale ... widzialem na wifi dlugie opoznienia.
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.
Piotrek
Guest
Guest
Sat Dec 28, 2019 7:47 pm
On 28-Dec-19 17:16, heby wrote:
Quote:
Albo to jest jeszcze jedna z tych skrajnie dziadowskich "technologii" w
automatyce albo nie potrafie się doczytać jak to ma działać poprawnie.
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
heby
Guest
Guest
Sat Dec 28, 2019 8:06 pm
On 28/12/2019 19:47, Piotrek wrote:
Quote:
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.
Quote:
ale konkretnie dla
modbus - bo zgaduję, że o to pytasz - są rozmaite wynalazki
programistyczne (np. mbusd)
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.
Quote:
https://www.aliexpress.com/item/32934899607.html), które realizują
konwersję protokołu modbus RTU <-> modbus TCP.
konwersję protokołu modbus RTU <-> modbus TCP.
Dam radę zrobić na Pi.
Quote:
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
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.
Mirek
Guest
Guest
Sat Dec 28, 2019 9:24 pm
On 28.12.2019 20:06, heby wrote:
Quote:
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.
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.
heby
Guest
Guest
Sat Dec 28, 2019 9:37 pm
On 28/12/2019 21:24, Mirek wrote:
Quote:
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?
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?)
Quote:
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.
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
J.F.
Guest
Guest
Sat Dec 28, 2019 9:39 pm
Dnia Sat, 28 Dec 2019 21:24:25 +0100, Mirek napisał(a):
Quote:
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.
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.
jacek pozniak
Guest
Guest
Sun Dec 29, 2019 3:15 pm
heby wrote:
Quote:
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.
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
heby
Guest
Guest
Sun Dec 29, 2019 3:45 pm
On 29/12/2019 15:15, jacek pozniak wrote:
Quote:
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 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ń.
Quote:
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.
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
Piotr Wyderski
Guest
Guest
Sun Dec 29, 2019 4:01 pm
heby wrote:
Quote:
Sporo programów ma opcje komunikacji z RS485 przez TCP.
Ale że co, chcesz się dowiedzieć, jak wystawiają MODBUS na porcie 503?
Pozdrawiam, Piotr
heby
Guest
Guest
Sun Dec 29, 2019 4:06 pm
On 29/12/2019 16:01, Piotr Wyderski wrote:
Quote:
Sporo programów ma opcje komunikacji z RS485 przez TCP.
Ale że co, chcesz się dowiedzieć, jak wystawiają MODBUS na porcie 503?
Ale że co, chcesz się dowiedzieć, jak wystawiają MODBUS na porcie 503?
Chce wiedzieć jak wygląda standardowy protokół przemysłowy RS485 over
TCP. Jak na razie po przeczytaniu internetów zakładam że wygląda nijak,
czyli strumień z TCP wciskany jest w UART bez zmian i tyle. Co generuje
ten "drobny detal" w postaci problemów ze znakowaniem konca ramki.
jacek pozniak
Guest
Guest
Sun Dec 29, 2019 4:56 pm
heby wrote:
Quote:
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.
No może, ale jeśli wyślesz tylko ala, w jednym kawałku, to jest praktycznie
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.
No może, ale jeśli wyślesz tylko ala, w jednym kawałku, to jest praktycznie
100% szansy, że z drugiej strony rury, wylezie to samo.
Jeśli nie, ponowisz transmisję.
Quote:
Ponadto nie ma czegoś takiego jak ramka tcp na poziomie aplikacji
Jest strumień.
No tak ale konstruktorzy/programiści urządzeń komutujących też chyba starają
Jest strumień.
No tak ale konstruktorzy/programiści urządzeń komutujących też chyba starają
się całe ramki słać i jeśli nie trzeba to nie kroją na kawałki.
Quote:
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
No trochę mało to eleganckie jest ale chyba nie ma stosownych unormowań w
tym zakresie (poza ModbusTCP).
Taki konwerter jest odpowiedzią na doraźne zapotrzebowanie do określonych
zastosowań.
jp
--
jp
www.flowservice.pl
www.flowsystem.pl
jacek pozniak
Guest
Guest
Sun Dec 29, 2019 4:58 pm
heby wrote:
Quote:
On 29/12/2019 16:01, Piotr Wyderski wrote:
Sporo programów ma opcje komunikacji z RS485 przez TCP.
Ale że co, chcesz się dowiedzieć, jak wystawiają MODBUS na porcie 503?
Chce wiedzieć jak wygląda standardowy protokół przemysłowy RS485 over
TCP. Jak na razie po przeczytaniu internetów zakładam że wygląda nijak,
czyli strumień z TCP wciskany jest w UART bez zmian i tyle. Co generuje
ten "drobny detal" w postaci problemów ze znakowaniem konca ramki.
Ale przepychanie danych przez konwerter a ModbusTCP to dwie różne sprawy.
Sporo programów ma opcje komunikacji z RS485 przez TCP.
Ale że co, chcesz się dowiedzieć, jak wystawiają MODBUS na porcie 503?
Chce wiedzieć jak wygląda standardowy protokół przemysłowy RS485 over
TCP. Jak na razie po przeczytaniu internetów zakładam że wygląda nijak,
czyli strumień z TCP wciskany jest w UART bez zmian i tyle. Co generuje
ten "drobny detal" w postaci problemów ze znakowaniem konca ramki.
Ale przepychanie danych przez konwerter a ModbusTCP to dwie różne sprawy.
jp
--
jp
www.flowservice.pl
www.flowsystem.pl
heby
Guest
Guest
Sun Dec 29, 2019 5:06 pm
On 29/12/2019 16:56, jacek pozniak wrote:
Quote:
No może, ale jeśli wyślesz tylko ala, w jednym kawałku, to jest praktycznie
100% szansy
100% szansy
Jak się zamknie jedno oko i popchnie wajche to może silnik się nawet
właczy prawie na 100% ;)
Quote:
Ponadto nie ma czegoś takiego jak ramka tcp na poziomie aplikacji
Jest strumień.
No tak ale konstruktorzy/programiści urządzeń komutujących też chyba starają
się całe ramki słać i jeśli nie trzeba to nie kroją na kawałki.
Jest strumień.
No tak ale konstruktorzy/programiści urządzeń komutujących też chyba starają
się całe ramki słać i jeśli nie trzeba to nie kroją na kawałki.
Nie da się wysłać "ramki" w TCP. To jest ograniczenie i ficzer
protokołu. Do wysyłania ramek jest UDP.
Quote:
Taki konwerter jest odpowiedzią na doraźne zapotrzebowanie do określonych
zastosowań.
zastosowań.
"Mamy zapotrzebowanie żeby działało na 99.9% bo elektrownia nuklearna".
elektroda NewsGroups Forum Index - Elektronika Polska - Jak wygląda praktyczne działanie konwerterów TCP/IP na RS485?