Konwerter TCP/IP<->RS485

Dnia Sat, 28 Dec 2019 00:32:17 +0100, heby napisał(a):

ethernet jest szybki, caly pakiet sie zmiesci w jednym znaku RS :-)

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.

Internet już nie.

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.

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.

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.

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

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.

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.

Dam radę zrobić na Pi.

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.

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

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

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.

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

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ń.

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

Ale że co, chcesz się dowiedzieć, jak wystawiają MODBUS na porcie 503?

Pozdrawiam, Piotr

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.

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ę.

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.

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

Ale przepychanie danych przez konwerter a ModbusTCP to dwie różne sprawy.

jp

Jak się zamknie jedno oko i popchnie wajche to może silnik się nawet właczy prawie na 100% ;)

Nie da się wysłać "ramki" w TCP. To jest ograniczenie i ficzer protokołu. Do wysyłania ramek jest UDP.

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

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

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.

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

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.

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.

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)

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.

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.

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