Konwerter TCP/IP<->RS485

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

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 demonizujesz problem przełączenia kierunku. To trwa tyle ile zbocze sygnału cyfrowego :) P.G.

Reply to
Piotr Gałka
Loading thread data ...
Reply to
invalid unparseable

I działa perfekcyjnie w ramach tych 99.9%.

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

Serio? A jak zgadniesz gdzie jest koniec ramki w TCP? Mówie o pzypadku wysyłania ramki *do* urządzenia, TCP->RS485.

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

A już takim w którym jest śjakieś 30 sek na timeout po zamknięciu socketa i otwarciu to na pewno ;)

Reply to
heby

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.

Reply to
heby

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.

Reply to
heby

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.

O to raczej mi chodzi. Czy na tym "raczej" bazują te konwertery czy może na czymś pewniejszym niż cicha modlitwa?

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.

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.

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.

Jesli tak to się nie nadają do modbusa.

, stosowałem w bezpośredniej

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.

Z uwagi na to że modbus rtu bazuje na timeoutach a tcp nie, nie może być przezroczysty. To bład logiczny.

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.

Reply to
heby

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

Reply to
jacek pozniak

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

Trudno wymagać więcej, to proteza. Koszerne rozwiązanie to Modbus TCP.

Reply to
Grzegorz Niemirowski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.