On 28/12/2019 21:24, Mirek 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.
> 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?

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

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

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