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.