On 27/04/2021 13:23, J.F wrote:
> Hm, wydaje mi sie, ze TR nie widzialem w watku.
> Chyba, ze od strony logicznej.

Tak, propozycja "nowej magistrali" przypomina zmielenie tokenring z canem.

> Teraz to moze i uzycia gotowej biblioteki, ale dawniej - wybor TCP/IP
> nie byl taki oczywisty, a i o bilioteke trudniej.

No idalej się wciska konwertery na modbus. To nie jest uzasadnialne
logicznie, to problem białkowy.

> Ale odpornosc na zaklocenia elektryczne jakby podobna.

Zaryzykuje że ethernetu większa: bo ramka krótsza.

>> Podstawowym problemem z RS485 jest blokowanie
>> magistrali kiedy urządzenie ustala zeznania.
> Ale to juz kwestia logicznej organizacji.

Nie. Nic nie zrobisz, pytasz i *oczekujesz* odpowiedzi, w tym czasie
nikt inny nie może transmitowac.

> Mozesz sobie cos ala kolizje ethernecie zorganizowac,

Po co, skoro jest ethernet?

> mozesz Token Ring, mozesz wymagac szybkiej odpowiedzi.

To nie jest kompatybilne z czymkolwiek, poza moim rękodziełem. Ethernet
jest kompatybilny ze wszystkim.

>> Jak już wspomniałem: jak chcesz magistralę RT to do tego powstał can.
>> Ale jak weźmiesz szybki ethernet, to zaryzykuje że i tak dostarczy
>> szybciej niż can.
> Tez zaryzykuje ... ale gwarancji nie ma.

A w can jest? Też nie ma gwarancji że ramkę dostarczy.

> A jak jeszcze sa bledy mozliwe, to juz w ogole gwarancji nie ma.
> Choc ze switchami powinno w miare szybko przejsc.

Ramki w ethernecie gineły w latach 90tych. Obecnie nie giną, chyba że
wysycisz pasmo.

> No, kiedys byly huby. Z kolizjami. Juz nie ma.
> Ale ale ... jak dasz interfejsy Modbus/LAN, to chyba znow mozliwa
> transmisja asychroniczna, bez blokowania kanalu :-)

Wtedy modbus zbędny, tylko blokuje koncept swoimi wadami.

>> Napisanie własnego konwertera tcp<>modbus to, zgaduje, koło 100 linijek,
> Cos pisales o protokolach pisanych na kolanie :-)

No ta w konwerterach właśnie takie są. Polegają na timeoutach TCP. Jak
spora częśc automatyki i informatyki, workaroundy pisane na kolanie
stały się standardem.

>> zakładając że mam gotowy stos tcp (a zazwyczaj mam).
> Teraz. Oczywiscie po wyborze odpowiedniego procka.

No i o to teraz chodzi. Przykład z niemieckim pudełkiem pełnym
workaroundów ma tylko ilustrować potencjalny kierunek uzasadnienia
dlaczego nie.

>>> Ale z kolei TCP moze miec dlugi czas repetycji po bledzie.
>> Więc zdecyduj: pasmo czy responsywaność.
> A czemu ja?

Ktoś musi ;)

>> Dodatkowo ten "długi czas" brzmi jak mgnienie oka w porównaniu z
>> modbusowymi lagami.
> A tu juz nie masz gwarancji.
> W dodatku trudno ten czas w TCP okreslic, bez grzebania w bibliotece.
> To sie panie automatycznie dobiera :-)

O ile masz właczony stosowny algorytm. Możesz wysyłać "natychmiast" albo
użyć UDP, albo użyć USP + QoS.

> A jak jeszcze gdzies po drodze jest wifi ... nie wiem jak oni to
> robia, ale widzialem sekundowe opoznienia.

Tak, ale Wifi nie jest przecież standardem przemysłowym, choć jest
standardem suwerenowym obsługi wszystkiego.

> A w automatyce ... czy nie kolejne utrudnienie?
> Bo np odpytujesz czujnik1. Czytasz czujnik2. Podejmujesz decyzje.
> No ale przyszla odpowiedz od 2, a od 1 ciagle nie.
> W pewnym moemencie przychodzi. Takie przerwanie dostajesz.
> Ale nie wiadomo, z ktorego momentu ta odpowiedz...

Ogarniamy to od 50 lat, w programowaniu. Automatycy też sobie poradzą.

>> A mój falownik nie może sobie otworzyć jakiegoś portu po TCP wprost i
>> ustępniać jakieś proste webapi? Wielodostęp, brak timeoutów, strumień a
>> nie pakiet. Same zalety. Nie, musi modbus.
> Moze. Ale do automatycznego sterowania lepszy jakis prosty protokol,
> czy cale WebApi?

Zabawnośc polega na tym że to całe "webapi" jest 20x prostsze i
samoopisujace niż idityzmy modbusa.

> A potem jeszcze dostosuj iles tam programow do WebApi,
> niestandardowych :-)

Ależ one zazwyczaj są standardowe. Jakiś json i okolice.

>>> Poza tym domyslam sie, ze Modbus mial duzo oprogramowania po obu
>>> stronach, i latwiej bylo mu dodac dodatkowa komunikacje po LAN/IP, niz
>>> wymyslac od nowa.
>> Po stronie apliakcji na telefon nie miał. Nadziobane od zera, widać to
>> po wersjach biblitek jakich używa.
> Nie mial. Ale teraz juz jakies sa jak widac.
> Wymyslisz cos lepszego ... i wszystko stare do kosza?

Nic nie było do kosza. Aplikację pisano od zera, od razu z tą kupą
workaroundów. Te falwoniki nie istniały kilka lat temu, tym bardziej appka.

>> Po stronie kontrolera w falowniku nie przypuszczam - to nowy produkt.
> Nowy produkt ale ze starym Modbusem?

Jak wszystko współczesne.

> A jakby wymyslili wszystko na nowo, lepiej, to co z cala reszta - znow
> dziobac od zera ?

Ten modbus uniemożliwia wiele rzeczy. Na przykład uniemożliwia poprawną
autoryzację z braku warstwy szyfrującej, więc zrobiono na modbusie
idiotyczny workaround, przesyłając hasło po kawałku do rejestrów licząc
na to że nikt nie zauważy. Nie ma to jak projektować od razu z
workaroundami, w dodatku na widok których programista security osiwiałby.

>> To nie kwestia mody. Modbus me niebotyczną ilość głopot, z punktu
>> widzenia proaktycznego nie przeszedł by nawet jako projekt na zaliczenia
>> laborki, a jest standardem przemysłowym.
> Widac nie jest taki zly.

Jest. Tylko przyschło. ZNnakomita większosć użytkowników dowolnej
technologii nie ma tendencji do zastanawiania się co jest popsute. Co
nie znaczy, że jest dobre.

>> Ethernet wiele z tych głupot usuwa, ale nie jest standardem,
>> przynajmniej nie jest uważany za kandydata.
> A jednak sie wciska.
> Przy czym jak pisalem - sam Ethernet to za malo.

Sam z siebie rozwiązuje wszystkie krytyczne problemy modbusa.

> A jak widac - wciska sie chocby przez interfejsy Modbus/LAN/IP.

Z krytycznym bugiem ;)

>> Powody histyczne, ale ileż można gadać że to wina Tus^M^M^M8051?
> Ale to nie tylko wina 8051.
> Troche tych malych prockow bylo, ethernetu nie mialy.

Ale to było dawno temu, za Łokietka. To niech sobie je wrapują
konwerterami. Problem nie ze starociami, problem z tym że będę miał
wyprodukowany kilka dni temu rekuperator z modbusem zamiast mqtt.

> Z kolei "lepszy procek" czesto oznaczal cala maszyne, podobna do PC.

Nie. Przesadzasz. Lepszy procek to najczęsciej 8051->STM32/Kinetis.
Zaryzykuje że developerka na takim jest kilkadziesiąt razy szybsza, bo
kompilatory normalne i procesor normalny.

> No ale chesz ten internet. Przynajmniej tak sie wydaje.

Chce mieć taką możliwośc. Dlaczego telemetria nie mogła by się np.
odbywać przez GSM, zaszyfrowanym kanałem tak samo jak metr dalej po drucie?

Ethernet to tak naprawdę tylko taki wytrych. Pradę mówiąc, chodzi o
ogólny koncept sieci.

>> Przykładowo: ponieważ wszelkie konwertery modbus<->ethernet po TCP
>> mają błąd (zależności czasowe i krojenie pakietów) to NIE da się ich
>> użyć w VPNie.
> Nie bardzo rozumiem, ale niech bedzie.

Kretyni którzy to projektowali, zapomnieli że TCP to strumień a nie
protokół pakietowy. O ile w LANie to przechodzi cudem, to w przypadku
VPN pakiety tego strumienia sią krojone i składane ponownie. Efektem
czego write (buf, 100) może przyjsc w kawałkach, np. read(buf, 90),
read(buf,9) i po dwóch sekundach read(buf,1). To jest poprawny strumień,
ale "pakiety" są już zupełnie inne. Dlatego, bo tam ich nie ma. Jest
tylko strumień.

W efekcie nie nadaje się to do modbusa, w którym jest pełno zaleznosci
czasowych.

Ale w LANie działą przypadkiem. Więc produkuje się te buble.

>> Efektem czego automatycy drą ryja że się nie nadaje, bo
> Ale co sie nie nadaje - VPN ?

W LAN działa, wstawiasz w chmurę i nie działa. Wina ethernetu!

> O to to to :-)
> Szambo ... ale nowe szambo za drogie :-)

Ale większe i komfortowe, z bąbelkami i biczowaniem.

> No dobra - dzis bym IP nie robil na czyms innym niz ethernet ... ale
> zaraz - swiatlowod tani i ma dodatkowe zalety :-)

I zerowy udziała w automatyce Januszowej, niech zgadnę.

> Przy czym te przykladowe karty moga rozwalic koncepcje, no ale raczej
> nie zakladamy tak wolnych mediow ... chyba, ze satelita?
> A "chmura w Kaliszu" ... oj, przydaloby sie opisac, co masz na mysli.

Nic. Abstrakcje mam na myśli. Jeśli protokół poprawny, to środki
komunikacji bez znaczenia.

>>> A w rakiecie pewnie gowniana transmisja szeregowa byla :-)
>> Ale za to system operacyjny z wywłaszczaniem i projektowany nie na kacu.
>> Nie do ogarnięcia na 8051 do dzisiaj.
> Podejrzewam, ze 8051 by go ogarnal.

Wywłaszczanie?

> I co teraz - bedziesz chwalil? :-)

Nie, przeciez 8051 to kupa była w momencie projektowania. Nic się nie
zmieniło od starożytności.

>>> Timeout ... przy braku bledow IMO nie przeszkadzaja w szybkosci.
>> Przeszkadza zasadniczo, bo nie możesz multiplexować wielu transmisji na
>> jednym kablu *jednocześnie*. W ethernecie możesz.
> TRzeba dopisac "slave musi rozpoczac odpowiedz w ciagu 1ms".

To problem wyższej warstwy. Magistrala może gadać z takimi co mówią
szybko, wolno, randomicznie itd itp. Ogarnia się to w sofcie. Potrafimy.

> Ethernecie moze to i nie przeszkadza, ale w sterowaniu juz
> przeszkadza, skoro musisz czekac na dane.

W modbusie też musisz czekać na dane. Tylko tam nie masz wyjścia, żeby w
tzw międzyczasie puścić sobie osobny strumień porno na stanowisko
operatora lub pogadać z czujnikiem krańcowym.

Multitasking. Takie problemy ogarniamy co najmniej od 60 lat.

> Albo taki np STOP. Wciskasz przycisk, maszyna ma sie zatrzymac, ale
> pakiet sie gdzies zgubil - jak dlugo czekamy na wyslanie ponowne?

Ten problem występuje we *WSZYSTKICH* magistralach. Bez wyjątku. I mam
zawsze tą sama rade: pociągnij do tego drut.

> Trzeba UDP i waznosc wprowadzic - taki Stop powtarzamy co 10ms, chyba,
> ze odbiorca potwierdzil :-)

Do tego jest np. MQTT. Gwarantują, że jesli odbirca żyje, to dostanie
wiadomość i to jest *pewne*.

>> To problem białkowy. Na ten przykład Roomba implementuje MQTT. Nie
>> musieli patrzeć na badziewie w automatyce i nie mają modbusa. Skandal.
> Pewnie jakbym poszukal, to bym znalazl spis wad MQTT :-P

O bez wątpienia. Tylko że ja od dawna szukam takiej listy zalet modbusa
i mam z tym kłopot. Choc nie, jest jedna: jest.

> Projektowali pewnie adekwatnie do czasu powstania.

Tak, w zeszłym wieku.

> No ale skoro taki popularny ... widac dobry :-P

Jak modbus. Też popularny. Widać dobry. A nie, czekaj...