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

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

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

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

do góry

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

do góry

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.

do góry

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

I działa perfekcyjnie w ramach tych 99.9%.

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

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

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

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

Łomatko, aleś wymyślł, znakowanie ramek poprzez zamykanie socketu :D
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.

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

do góry

On 30/12/2019 11:57, Piotr Gałka wrote:
> 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.

do góry

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.

do góry

On 29/12/2019 23:02, jacek pozniak wrote:
> 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.

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

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

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

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

> Konwertery nie wprowadzają, żadnego narzutu

Jesli tak to się nie nadają do modbusa.

, stosowałem w bezpośredniej
> 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.

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

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

do góry

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

do góry

heby <h...@p...onet.pl> napisał(a):
> 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/

do góry