RTV forum PL | NewsGroups PL

Konwerter TCP/IP<->RS485

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Konwerter TCP/IP<->RS485

Goto page Previous  1, 2

jacek pozniak
Guest

Sun Dec 29, 2019 7:32 pm   



Quote:
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.
Czepiasz się słówek. Urządzenia komutujące operują na warstwie IP lub

podobnej.
Raczej nie ciachają Twojego strumienia w dowolnym miejscu. Przynajniej tak
mi się wydaje.

jp

Quote:

Taki konwerter jest odpowiedzią na doraźne zapotrzebowanie do określonych
zastosowań.

"Mamy zapotrzebowanie żeby działało na 99.9% bo elektrownia nuklearna". Very Happy

--
jp

www.flowservice.pl
www.flowsystem.pl

heby
Guest

Sun Dec 29, 2019 9:19 pm   



On 29/12/2019 19:32, jacek pozniak wrote:
Quote:
Nie da się wysłać "ramki" w TCP. To jest ograniczenie i ficzer
protokołu. Do wysyłania ramek jest UDP.
Czepiasz się słówek.

Obawiam się że to jest znacznie większa różnica niż tylko słówko.

Quote:
Urządzenia komutujące operują na warstwie IP lub
podobnej.
Raczej nie ciachają Twojego strumienia w dowolnym miejscu.

Ciachają, tylko że te ciachnięcia w przypadku strumienia to tylko
opóźnienia odczytu i zachwoania funkcji read po stronie odbiorcy.

Quote:
Przynajniej tak
mi się wydaje.

Ogólnie strumień nie jest w zasadzie ciachany. Po prostu bajty
przychodza jeden po drugim i to jak zostały wygenerpowane na stacie
(przerwy, długości zapisów itd itp) nie ma wpływu na to jak zostaną
odebrane.

Nadajnik wysyła coś i robi przerwę a po stronie odbiorcy przylatuje
posklejane albo pocięte w innych miejscach. Strumień jest strumień,
liczy się tylko kolejnośc bajtów i tylko to jest zagwarantowane,
zależności czasowe znikają po wielokrotnym enkapsulowaniu. A modbus
wymaga zależności czasowych.

To jest właśnie główna róznica z protokołem UDP. W UDP masz pewnośc że
dostaniesz dane w "ramce" w takiej formie jak ją wysłałeś. W TCP ramek
nie ma, jest ciągle kapiący strumień bajtów, jeden po drugim, bez
żadnych dodatkowych informacji.

jacek pozniak
Guest

Sun Dec 29, 2019 11:02 pm   



heby wrote:

Quote:
On 29/12/2019 19:32, jacek pozniak wrote:
Nie da się wysłać "ramki" w TCP. To jest ograniczenie i ficzer
protokołu. Do wysyłania ramek jest UDP.
Czepiasz się słówek.

Obawiam się że to jest znacznie większa różnica niż tylko słówko.

Urządzenia komutujące operują na warstwie IP lub
podobnej.
Raczej nie ciachają Twojego strumienia w dowolnym miejscu.

Ciachają, tylko że te ciachnięcia w przypadku strumienia to tylko
opóźnienia odczytu i zachwoania funkcji read po stronie odbiorcy.

Przynajniej tak
mi się wydaje.

Ogólnie strumień nie jest w zasadzie ciachany. Po prostu bajty
przychodza jeden po drugim i to jak zostały wygenerpowane na stacie
(przerwy, długości zapisów itd itp) nie ma wpływu na to jak zostaną
odebrane.
Strumień, o ile nie przesyłasz po RS232, JEST ciachany, przy nadawaniu bo

jest obudowywany w ramki IP, po 1400 bajtów lub miej, jeśli socket uzna, że
już się nazbierało dość danych do wysłania lub jakaś tam przerwa w napływie
danych jest.
Jeśli te dane się zmieszczą w 1400 bajtach to raczej przyjdą w jednym
kawałku bo do rozmiaru ramki IP są zazwyczaj dostosowane pozostałe elementy
infrastruktury.


Quote:

Nadajnik wysyła coś i robi przerwę a po stronie odbiorcy przylatuje
posklejane albo pocięte w innych miejscach. Strumień jest strumień,
liczy się tylko kolejnośc bajtów i tylko to jest zagwarantowane,
zależności czasowe znikają po wielokrotnym enkapsulowaniu. A modbus
wymaga zależności czasowych.
Mówisz tu o pryncypiach ale wątek jest o konwerterze, który został wymyślony

prawdopodobnie do zastosowań Modbus.


Konwerter działa, wykorzystuje TCP, i raczej nie ma tu mowy o robieniu
jakichś przypadkowych przerw pomiędzy bajtami.
Po prostu on wysyła całe zapytanie, prawdopodobnie w ramach jednego segmentu
danych i z konwertera po drugiej stronie wychodzi tak samo.
Konwertery nie wprowadzają, żadnego narzutu, stosowałem w bezpośredniej
współpracy konwertera ze skryptem bashowym; transmisja szła poprzez jakieś
telewizje kablowe czy coś podobnego.

Takie zachowanie powoduje, że jest on przeźroczysty dla Modbusa (no moze
opóźnienia większe mogą się zdarzyć ale to nie narusza protokołu)

Quote:

To jest właśnie główna róznica z protokołem UDP. W UDP masz pewnośc że
dostaniesz dane w "ramce" w takiej formie jak ją wysłałeś. W TCP ramek
nie ma, jest ciągle kapiący strumień bajtów, jeden po drugim, bez
żadnych dodatkowych informacji.
Może w tych konwerterach (ACT-2000) można ustawić aby chodziło po UDP ale

nie stosowałem bo nie daje gwaranci dostarczenia danych.


--
jp

www.flowservice.pl
www.flowsystem.pl

Marek
Guest

Mon Dec 30, 2019 1:38 am   



On Sun, 29 Dec 2019 16:06:25 +0100, heby <heby@poczta.onet.pl> wrote:
Quote:
TCP. Jak na razie po przeczytaniu internetów zakładam że wygląda
nijak,

Jakich internetow? Obawiam się, że czytałeś opisy tworzone przez
użytkowników-praktyków a nie architektów implementacji. Ci pierwsi
często między sobą powtarzają uatrte (często błędne) mniemanie co jak
działa....W automatyce to częste.

--
Marek

Piotrek
Guest

Mon Dec 30, 2019 10:52 am   



On 28-Dec-19 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.

Wprawdzie można to zaprogramować dowolnie debilnie (np. socatem w
internetach), ale przecież w takim konwerterze nie musisz mieć prostego
passthrough. Możesz mieć proces konsumujący znaki z RS485, którym jesteś
w stanie wychwycić koniec ramki. I wtedy wysyłasz pakiet w internety
otwierając i zamykając socket. Co pozwoli drugiej stronie stwierdzić
kompletność ramki.

Nie upieram się, że to najlepsze rozwiązanie ale działać powinno w
dowolnym środowisku.

Piotrek

Piotr Gałka
Guest

Mon Dec 30, 2019 11:57 am   



W dniu 2019-12-28 o 21:39, J.F. pisze:

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.

To "natychmiast" to chyba symbolicznie, bo kazdy system komputerow ma
jakis tam czas reakcji.

Wypowiadam się w kontekście RS485 a nie modbus.
Można tak zrobić protokół na RS485, że 'natychmiast' ma przyjść
potwierdzenie, że ramka dotarła, a odpowiedź na nią (wymagająca np.
czasochłnnego wyszukania czegoś w pamięci) zostanie przysłana jako
osobna transmisja inicjowana przez drugą stronę. W międzyczasie
magistrala jest dostępna dla innych urządzeń, które mogą mieć 'coś do
wysłania'.
Urządzenie odbierające zna format ramki więc wie który bajt będzie
ostatni i może się odezwać zaraz po jego bitach stopu.

Kiedyś dawno testowaliśmy kiedy UART informuje o odebraniu bajtu. Wyszło
nam, że zarówno na PC jak i procku już gdzieś w połowie pierwszego bitu
stopu (niezależnie czy format jest ustawiony na jeden, czy dwa bity
stopu) bajt jest już 'odebrany'.
Jeśli w czasie 1.5 bitu stopu da się sprawdzić ramkę (czy do mnie i crc)
to praktycznie od razu po jej zakończeniu można zacząć wysyłać
potwierdzenie.

Ja nie piszę, że wysyłanie natychmiast potwierdzenia jest rozsądne,
piszę tylko, że tak da się zrobić.
Według mnie rozsądniejsze (ze względu na zajętość szyny) jest założenie,
że ramka doszła i kiedyś tam przyjdzie odpowiedź (nie koniecznie w
pierwszej ramce jaka się pojawi). Brak odpowiedzi w określonym czasie to
inny temat.

Quote:
Chyba, ze sprzetowe urzadzenie ... ale przeciez trzeba jeszcze kirunek
przelaczyc ...

Chyba demonizujesz problem przełączenia kierunku. To trwa tyle ile
zbocze sygnału cyfrowego Smile
P.G.

marfi
Guest

Mon Dec 30, 2019 1:35 pm   



Użytkownik "J.F." <jfox_xnospamx@poczta.onet.pl> napisał w wiadomości
news:1l0rez59e3p8k.o0nmqw07z2f7$.dlg@40tude.net...
Quote:
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 Smile

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

J.F.
Guest

Mon Dec 30, 2019 2:49 pm   



Użytkownik "marfi" napisał w wiadomości grup
dyskusyjnych:5e09ef8c$0$503$65785112@news.neostrada.pl...
Użytkownik "J.F." <jfox_xnospamx@poczta.onet.pl> napisał w wiadomości
Quote:
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.

heby
Guest

Wed Jan 01, 2020 7:01 pm   



On 30/12/2019 10:52, Piotrek wrote:
Quote:
Wprawdzie można to zaprogramować dowolnie debilnie (np. socatem w
internetach)

I działa perfekcyjnie w ramach tych 99.9%.

Quote:
, ale przecież w takim konwerterze nie musisz mieć prostego
passthrough.

A mam coś wypasionego w środku? Właśnie na to poszukuje odpowiedzi.

Quote:
Możesz mieć proces konsumujący znaki z RS485, którym jesteś
w stanie wychwycić koniec ramki.

Serio? A jak zgadniesz gdzie jest koniec ramki w TCP? Mówie o pzypadku
wysyłania ramki *do* urządzenia, TCP->RS485.

Quote:
I wtedy wysyłasz pakiet w internety
otwierając i zamykając socket.

Łomatko, aleś wymyślł, znakowanie ramek poprzez zamykanie socketu Very Happy
Problem z detekcją występuje w druga stronę: w jaki sposób konwerter
TCP->RS485 wykrywa koniec ramki na strumieniu TCP. Jeśli robi to
timeoutem to robi to ... źle. Przy czytaniu, jako że nadawca wie ile
bajtów ma dostać, wykrycie konca ramki która przyszła z urządzenia jest
osiągalne w miarę sensownie. O ile urządzenie zwraca odpowiedzi o znanej
ilosci znaków.

Quote:
Nie upieram się, że to najlepsze rozwiązanie ale działać powinno w
dowolnym środowisku.

A już takim w którym jest śjakieś 30 sek na timeout po zamknięciu
socketa i otwarciu to na pewno Wink

heby
Guest

Wed Jan 01, 2020 7:03 pm   



On 30/12/2019 11:57, Piotr Gałka wrote:
Quote:
Wypowiadam się w kontekście RS485 a nie modbus.

To tylko sygnalizuje że problem o którym piszę w wątku jest problemem
czysto TCP i nie ma związku z RS485. Wybrałem złośliwie modbus@RS485
(RTU) dlatego że ten protokół projektowani geniusze którzy zapomnieli
dodać pole określajace rozmiar ramki w tejże ramce. Generując problemy
takie o których mówie.

heby
Guest

Wed Jan 01, 2020 7:04 pm   



On 30/12/2019 01:38, Marek wrote:>> TCP. Jak na razie po przeczytaniu
internetów zakładam że wygląda nijak,> Jakich internetow?

Opisujących trywialne konwertery TCP->modbus/rtu. Jesli dobrze wyczytuje
to są tylko proxy strumienia tcp do strumienia uart i nic więcej.

heby
Guest

Wed Jan 01, 2020 7:14 pm   



On 29/12/2019 23:02, jacek pozniak wrote:
Quote:
Strumień, o ile nie przesyłasz po RS232, JEST ciachany, przy nadawaniu bo
jest obudowywany w ramki IP

Z punktu widzenia API nie jest. To że pod spodem jest krojony na pakiety
nie ma żadnego znaczenia, poza tym że znaki mogą przyjść z przerwami w
miejscach które są innne niż przerwy w nadawaniu. Z punktu widzenia TCP
nie ma żadnych ramek, jest strumień, ciągły.

Quote:
Jeśli te dane się zmieszczą w 1400 bajtach to raczej

O to raczej mi chodzi. Czy na tym "raczej" bazują te konwertery czy może
na czymś pewniejszym niż cicha modlitwa?

Quote:
Nadajnik wysyła coś i robi przerwę a po stronie odbiorcy przylatuje
posklejane albo pocięte w innych miejscach. Strumień jest strumień,
liczy się tylko kolejnośc bajtów i tylko to jest zagwarantowane,
zależności czasowe znikają po wielokrotnym enkapsulowaniu. A modbus
wymaga zależności czasowych.
Mówisz tu o pryncypiach ale wątek jest o konwerterze, który został wymyślony
prawdopodobnie do zastosowań Modbus.

Obawiam się że jeśli to jest tylko przerzucenie tcp->modbus rtu to taki
konwerter nie nadaje się do modbusa. Mam nadzieje że go nikt do takiego
zastosowania nie wymyślił, tylko się przypadkiem "przydał" przez
kreatywnych automatyków nie ogarniających tcp.

Quote:
Konwerter działa, wykorzystuje TCP, i raczej nie ma tu mowy o robieniu
jakichś przypadkowych przerw pomiędzy bajtami.

Ależ jest. TCP nie gwarantuje, nawet śladowo, że przerw nie będzie, bądź
będą jakieś określone. Nic nie gwarantuje poza kolejnoscią bajtów. A tu
pechowo przerwy są krytyczne dla modbusa.

Quote:
Po prostu on wysyła całe zapytanie, prawdopodobnie w ramach jednego segmentu
danych i z konwertera po drugiej stronie wychodzi tak samo.

Nie. Może wyjść w posób który urządzenie końcowe zinterpretuje jako
koniec nadawania ramki modbus i okaże się ona uszkodzona bo niepełna a
reszta przyjdzie a chwile.

Quote:
Konwertery nie wprowadzają, żadnego narzutu

Jesli tak to się nie nadają do modbusa.

, stosowałem w bezpośredniej
Quote:
współpracy konwertera ze skryptem bashowym; transmisja szła poprzez jakieś
telewizje kablowe czy coś podobnego.
Jak doskonale wiem że to działa w 99.9% przypadków. Sam to robie. Tylko

że też doskonale wiem że to jest wyłacznie naciągane. Przykładowo kiedy
uruchomie moje urządzenie przez VPN to zależności czasowe w tcp psują
się i czasami "ramki", nawet krótkie, dochodzą na dwie-trzy raty. Przy
kiepskim łaczu może to oznaczać błedne zinterperetowanie przerwy jako
końca ramki modbus.

Quote:
Takie zachowanie powoduje, że jest on przeźroczysty dla Modbusa (no moze
opóźnienia większe mogą się zdarzyć ale to nie narusza protokołu)

Z uwagi na to że modbus rtu bazuje na timeoutach a tcp nie, nie może być
przezroczysty. To bład logiczny.

Quote:
Może w tych konwerterach (ACT-2000) można ustawić aby chodziło po UDP ale
nie stosowałem bo nie daje gwaranci dostarczenia danych.

Podobnie jak używanie tcp nie daje gwarancji wygenerowania poprawnej
ramki modbus ponieważ może przyjśc przedwczesne opóźnienie na znakach i
urządzenie zinterpretuje to jako koniec ramki.

jacek pozniak
Guest

Thu Jan 02, 2020 11:02 am   



Zawsze możesz zbudować swóje własne rozwiązanie komunikacujne i próbować nim
ulepszać świat.

Nic nie jest doskonałe. I prawdę mówiąc, większość nie oczekuje, że ma takim
być.

jp


--
jp

www.flowservice.pl
www.flowsystem.pl

Grzegorz Niemirowski
Guest

Thu Jan 02, 2020 11:17 am   



heby <heby@poczta.onet.pl> napisał(a):
Quote:
Opisujących trywialne konwertery TCP->modbus/rtu. Jesli dobrze wyczytuje
to są tylko proxy strumienia tcp do strumienia uart i nic więcej.

Trudno wymagać więcej, to proteza. Koszerne rozwiązanie to Modbus TCP.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Goto page Previous  1, 2

elektroda NewsGroups Forum Index - Elektronika Polska - Konwerter TCP/IP<->RS485

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map