heby wrote:

> Sporo programów ma opcje komunikacji z RS485 przez TCP.

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

Pozdrawiam, Piotr

do góry

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.

do góry

heby wrote:

> 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
100% szansy, że z drugiej strony rury, wylezie to samo.
Jeśli nie, ponowisz transmisję.

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

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

do góry

heby wrote:

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

jp

--
jp

www.flowservice.pl
www.flowsystem.pl

do góry

On 29/12/2019 16:56, jacek pozniak wrote:
> No może, ale jeśli wyślesz tylko ala, w jednym kawałku, to jest praktycznie
> 100% szansy

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

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

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

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

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

do góry

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

>
>> Taki konwerter jest odpowiedzią na doraźne zapotrzebowanie do określonych
>> zastosowań.
>
> "Mamy zapotrzebowanie żeby działało na 99.9% bo elektrownia nuklearna". :D

--
jp

www.flowservice.pl
www.flowsystem.pl

do góry

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.

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.

do góry

heby wrote:

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


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

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

do góry

On Sun, 29 Dec 2019 16:06:25 +0100, heby <h...@p...onet.pl> wrote:
> 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

do góry

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

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

do góry