On 27/04/2021 10:07, Piotr Wyderski wrote:
> Przykro mi, jeśli Cię zawiodłem.

Nie zawiodłeś, do czegoś takiego są Zynq i jestem ciekaw czy są już
konkurencyjne do osobnego FPGA + CPU.

do góry

On Tue, 27 Apr 2021 10:39:17 +0200, heby wrote:
> On 27/04/2021 10:18, Marek wrote:
>>> typowy dzisiejszy projekcik w Arduino na 30 minut.
>> Ale z którego roku ta konstrukcja?
>
> Naprawiałem ją koło 2005 roku, przypuszczam że z 2001 bo takie były daty
> produkcji na scalakach z okolicy 8051. Nie znam właściciela ani historii
> tego cuda, dostałem pudełko, oddałem pudełko i tyle mojej wiedzy.

scalaki z 2001, ale projekt mogl byc duzo wczesniejszy.

Szczegolnie ze jak piszesz - najpierw moglo byc samodzielne
sterowanie, potem potrzeba dodania Modbus, potem potrzeba dodania LAN>

> Nikt nie oczekuje. Rzecz w czym innym: owszem, "nowoczesne" rozwiązania,
> takie jak ethernet wnikają w automatykę.

Wnikaja.

> Ale ponieważ to protezy na
> modbusa itp to w efekcie nie dają nic nowego. Dalej jest to samo
> dziadostwo, tylko na innym kablu. Nic dziwnego że automatyk na widok
> ethernetu krzywi się straszliwie. Z jego perspektywy w środku jest
> właśnie taki konwerter i wystawiony gówniany modbus na porcie tcp
> dodając tylko zbędną warstwę komplikacji, grubsze kable, jakies switche
> itd itp.

troche bym polemizowal.
Po pierwsze - sam ethernet niewiele daje. Transmisje pakietow tylko.
Musialbys go od golasa oprogramowac.
A wczesniej opracowac jakis standard, i starac sie, aby sie przyjal.
I dostowac programy do tego.
A potem bys trafil na bariere komunikacji na wieksza odleglosc.

No to masz kilka "zbednych" warstw, ale w zamian jakas tam
kompatybilnosc, adresacje IP, przechodzenie przez routery itp ...

> Mam falownik PV z wifi. Mam pompę z wifi. Zgadnij, co w obu wypadkach
> robi za to wifi. Podpowiadam: konwerter na modbusa.

Bo pewnie w srodku jest troche oprogramowania.
Znasz sie na falownikach, a teraz mialbys do tego dorzuci powyzsze -
to potrzebujesz kolejnego programiste.
Z ryzykiem, ze cos skopie.

Dodaj, ze falownik zrobiles na procku, ktory dobrze faluje ... ale nie
ma ethernetu.
zmieniac procek czy dokladac interfejs?

No to dolozyli, a ty sie pieklisz :-)

> Nie da się tego uzasadnić logicznie. Tym bardziej że jestem zmuszony
> pauzować strumień po TCP aby poprawnie rozpoznawało ramki, czyli wbrew
> koncepcji TCP. Widać, że projektował to automatyk a nie informatyk i
> działa przypadkiem.

A apetyt rosnie.
Nie wystarczy wifi, teraz musi np wspolpracowac z chmura google :-)

I bedzie postep, i nasze dzieci beda mialy prace :-)


J.

do góry

On 27/04/2021 10:33, J.F wrote:
>> 3) Ale do niej, zamiast kostki w dziurze obudowy, dopięty fabryczny
>> konwerter MODBUS<->LAN jakiejś innej firmy, we własnej obudowie,
>> fikuśnie zamocowany tak, że przez obudowę widać tylko dziurkę ethernetu.
>> W tamtych czasach takie konwertery kosztowały chyba więcej niż to
>> urzadzenie było naprawdę warte, razy 10.
> Zaraz zaraz - a jaki byl cel tego?

Nie wiem, bo nie widziałem całej maszyny. Być może marketingowy: "Mamy
ethernet".

> Sterowanie sterowane przez Ethernet?
> I jeszcze przez jakis nadrzedny program LAN-Modbus?

Tak.

Masa urządzeń tak działa. Nawet u mnie w domu pełno takich gotowców,
przykładowo apliakcja do pompy ciepła (po zdekompilowaniu) ujawniła że
ma w środku wrzucony inną aplikację producenta konwertera rs485<->wifi
tylko po to aby dać radę ten konwerter przypisać do sieci z poziomu
własnego GUI. Aplikację do konwertera poobcinano z elementów GUI i
bangla w środku innej. A zdekompilowałem, bo szukam rejestrów
modbusowych tej pompy, oficjalnie nie ma dokumentu.

> To jaka byla wtedy alternatywa?

RS232/RS485? Skoro wpieli to przez LAN, to nie zyskali nic ponad. Być
moze były powody które były by jasne po zobaczeniu reszty złomu.

> Dac malego peceta i posadzic tam np Linuxa?

Tam chodził jakiś komputer na starym Windowsie, kontrolujacy produkcję.
Nie wiem na pewno, ale to była jakas maszyna do pakowania i ten
sterownik sterował pneumatyką zginania tektury. Dużo tam do roboty nie
było, to nawet nie był system RT. Ot, dmuchnąc w siłownik we właściwej
kolejności i sprawdzic czy krańcówki zadziałały.

> Bo dzis ... Arduino moze i fajne, ale tak natywnie Ethernetu nie
> posiada.
> Dolozyc modul mozna, ale tak po prawdzie ... skladanka niemal godna
> tej, co opisujesz.

Zgadza się, Arduino padło jako argument do potencjalnego "nie da się
tego 8051 wyrzucić, jest konsekrowany i Hans zabrał kod źródłowy do
grobu". Da się, ale nikt tego nie robi bo ... nie da się albo się nie
opłaca.

>> Ogólnie problem magistrali (i technologii) w przemyśle wydaje mi się być
>> czysto biologiczny i tylko tak można go rozwiazać, jak rozwiązuje go
>> natura od lat. Dlatego tak ważne jest usunięcie 8051 z dydaktyki i
>> ustawowy zakaz na początek. Żeby przerwać łańcuch zła ;)
> W zasadzie tak, ale o w zamian?
> Arduino czy ARM ?

RISC-V. Ale na razie styknie ARM z jakimś STM32 za $2 na płytce u
chińczyka lub Discovery za kilka(naście) $.

>> Choć prawdę mówiąc, nie ma znaczenia co nowego wymyślimy. Jestem
>> przekonany że przy budowie windy kosmicznej czy nawet kolonizacji
>> gwiazd, będą pracowały urządzenia na modbus z lagiem 20 sekund na
>> odczyt,
> Ale czesto mniej nie trzeba, bo temperature sie mierzy powoli :-)

I dlatego pozostałe urządzenia na tej magistrali musza poczekać
grzecznie, bo się mierzy powoli... kto by tam miedź marnował na gwiazdy.

>> wyswietlaczem 7-seg LED, dwoma przyciskami ze skomplikowanym
> Ale ganisz ze ma wyswietlacz, czy ze 7-seg LED ?

Że ma *skomplikowane* menu i dwa przyciski +7seg. Podam przykład:

ftp://212.85.113.169/Instrukcje_obslugi/Instrukcje%2
0obslugi%20-%20nowe/Instrukcja_PECA17_v1_5x.pdf

PECA17 to dla mnie poziom podłogi, jeśli chodzi o budowę skomplikowanego
menu w urządzeniu do automatyki. Spieprzyli by chyba tylko bardziej,
gdyby był 1 przycisk. Doczekam się w końcu. To szaleństwo upraszczania
obsługi, a wszak 1 przycisk to prościej niż 2, więc lepiej.

>> ogranicza wolność druciarstwa i patriotyzm lokalnych producentów w
>> wymyślaniu kwadratowych kół.
> ale jesli znormalizowane wtyczki, to jakie ?

Nie wiem. Nie udało się wymyśleć przez 50 lat, nie uda się już nigdy. A
w ethernecie dali radę. Zadziwiające, jacy Ci informatycy "zniewoleni" ;)

do góry

heby <h...@p...onet.pl> napisał(a):
> Nie da się tego uzasadnić logicznie. Tym bardziej że jestem zmuszony
> pauzować strumień po TCP aby poprawnie rozpoznawało ramki, czyli wbrew
> koncepcji TCP. Widać, że projektował to automatyk a nie informatyk i
> działa przypadkiem.

Z informatykiem pewnie nie byłoby lepiej. Mało który ogarnia, że na poziomie
socketu nie ma pakietów tylko strumień bajtów, które mogą być różnie
posklejane. I sobie zakłada, że jak zrobi read() na sockecie, to dostanie
całą i tylko jedną ramkę warstwy aplikacyjnej.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 27/04/2021 10:54, J.F wrote:
> Szczegolnie ze jak piszesz - najpierw moglo byc samodzielne
> sterowanie

Raczej najpierw był RS232, sądząc po zaklejonej dziurze w obudowie ;)

> Po pierwsze - sam ethernet niewiele daje. Transmisje pakietow tylko.

Daje:
1) pseudo równoległość
2) odpornośc na zakłucenia
3) wyższe warstwy gwarantują dostarczenie wiadomości
4) automatyczny podziała pasma

> Musialbys go od golasa oprogramowac.

Nie, stosów od ethernetu po tcp jak mrówków.

> A wczesniej opracowac jakis standard, i starac sie, aby sie przyjal.

No i czekając na ten cud dalej uzywamy modbusa przebranego w ethernet.

> I dostowac programy do tego.

Zgadza się. Problemem jest białko.

> A potem bys trafil na bariere komunikacji na wieksza odleglosc.

Internet nie działa? Patrz: ethernet za friko zapewnia dużą odległość,
choćby na światełku, przez radiolinie, po VPNy.

> No to masz kilka "zbednych" warstw, ale w zamian jakas tam
> kompatybilnosc, adresacje IP, przechodzenie przez routery itp ...

I to wszystko działa w sposób, któego urządzenie końcowe nie widzi.

>> Mam falownik PV z wifi. Mam pompę z wifi. Zgadnij, co w obu wypadkach
>> robi za to wifi. Podpowiadam: konwerter na modbusa.
> Bo pewnie w srodku jest troche oprogramowania.
> Znasz sie na falownikach, a teraz mialbys do tego dorzuci powyzsze -
> to potrzebujesz kolejnego programiste.
> Z ryzykiem, ze cos skopie.

Napisali od zera oprogramowanie do falownika. I zapomnieli o komunikacji
wifi, a nie zapomnieli o modbusie? E...

> Dodaj, ze falownik zrobiles na procku, ktory dobrze faluje ... ale nie
> ma ethernetu.
> zmieniac procek czy dokladac interfejs?

Pozbyś się iditycznej, lagującej wastwy modbusa? Nie mogę odczytywać
parametrów falwonika częsciej "niż", ponieważ pod spodem jest gówniana
transmisja szeregowa czuła na timeouty. XXI wiek, przypominam, na
księżycu byliśmy podobno.

> No to dolozyli, a ty sie pieklisz :-)

Dołożyli protezę. Dzisiaj/jutro będa mi montować rekuperator. Zgadnij,
jakie mają rozwizanie automatyki domowej w tym reku. Podpowiem, że
standardowe dla XXIw w automatyce.

> Nie wystarczy wifi, teraz musi np wspolpracowac z chmura google :-)

I współpracuje, nie myśl sobie. Przez modbus i translator na serwerze w
chinach. Co prawda nie moja, ale mają taką opcję.

A MQTT nie ma w ani jednym z urządzeń. Bo po co ma być użyteczne.

do góry

On 27/04/2021 11:03, Grzegorz Niemirowski wrote:
>> Nie da się tego uzasadnić logicznie. Tym bardziej że jestem zmuszony
>> pauzować strumień po TCP aby poprawnie rozpoznawało ramki, czyli wbrew
>> koncepcji TCP. Widać, że projektował to automatyk a nie informatyk i
>> działa przypadkiem.
> Z informatykiem pewnie nie byłoby lepiej. Mało który ogarnia

Ja ogarniam i strasznie mnie to irytuje. Już kilka miesiący temu, na tej
grupie, wrzuciłem taki temat i okazało się że "nie ma problemu, przecież
działa". Super. Automatyka przemysłowa z tektury i paździerza.

do góry

On Tue, 27 Apr 2021 11:12:24 +0200, heby wrote:
> On 27/04/2021 10:54, J.F wrote:
>> Szczegolnie ze jak piszesz - najpierw moglo byc samodzielne
>> sterowanie
>
> Raczej najpierw był RS232, sądząc po zaklejonej dziurze w obudowie ;)
>
>> Po pierwsze - sam ethernet niewiele daje. Transmisje pakietow tylko.
>
> Daje:

Ty o zaletach sprzetowych, a ja o tym, ze sam ethernet to dopiero
poczatek, potem trzeba jeszcze duzo oprogramowania.

> 1) pseudo równoległość
> 2) odpornośc na zakłucenia

Hm, chyba podobna jak RS-485. Podobna technologia.

> 3) wyższe warstwy gwarantują dostarczenie wiadomości

No wlasnie - wyzsze warstwy. Jak sa. Jak sa dobrze oprogramowane, zeby
dostarczenie nastapilo w odpowiednim czasie.

> 4) automatyczny podziała pasma

No, w switchach, czy jeszcze z kolizjami ?

Poza tym w automatyce zwykle nie masz klopotow z pasmem ... za to jak
wrzucisz kilka "systemow" do jednej sieci ethernet, to sie moga
pojawic :-)
Choc switche separuja.

>> Musialbys go od golasa oprogramowac.
> Nie, stosów od ethernetu po tcp jak mrówków.

A owszem, ale to juz wybrales standard TCP/IP - i dobrze,
ale to nadal malo - cos trzeba w ramach tego standardu :-)
MODBUS po TCP/IP.

Ale z kolei TCP moze miec dlugi czas repetycji po bledzie.
Moze lepiej Modbus/UDP ? :-)

>> A wczesniej opracowac jakis standard, i starac sie, aby sie przyjal.
>
> No i czekając na ten cud dalej uzywamy modbusa przebranego w ethernet.

Powyzej nawet sie nie zajaknales nad czyms lepszym :-)

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.

>> I dostowac programy do tego.
> Zgadza się. Problemem jest białko.

Zaraz zaraz.
Masz w fabryce troche maszyn i czujnikow modbus/RS-485, i zgrabne
programy do zarzadzania tym wszystkim, i nagle chcesz powiedziec -
rzucmy to w cholere, kupimy wszystko w nowej, lepszej technologii?

Te maszyny grube miliony kosztowaly, i moga jeszcze 10 lat chodzic :-)

A potem sie komus USB spodoba, a innemu Bluetooth - i wszystko
kompletnie od nowa ?

>> A potem bys trafil na bariere komunikacji na wieksza odleglosc.
> Internet nie działa?

Internet dziala, ethernet nie.
Wiec musisz od razu internet wybrac.

> Patrz: ethernet za friko zapewnia dużą odległość,
> choćby na światełku, przez radiolinie, po VPNy.

No wlasnie - internet nie oznacza automatycznie Ethernetu :-)

>> No to masz kilka "zbednych" warstw, ale w zamian jakas tam
>> kompatybilnosc, adresacje IP, przechodzenie przez routery itp ...
>
> I to wszystko działa w sposób, któego urządzenie końcowe nie widzi.

I super.
A tu ktos dostawil dwa klocki do urzadzenia i tez dziala jak chcesz,
tylko uzytkownik koncowy ma oczy i widzi, choc nie powinien zagladac
:-)

>>> Mam falownik PV z wifi. Mam pompę z wifi. Zgadnij, co w obu wypadkach
>>> robi za to wifi. Podpowiadam: konwerter na modbusa.
>> Bo pewnie w srodku jest troche oprogramowania.
>> Znasz sie na falownikach, a teraz mialbys do tego dorzuci powyzsze -
>> to potrzebujesz kolejnego programiste.
>> Z ryzykiem, ze cos skopie.
>
> Napisali od zera oprogramowanie do falownika. I zapomnieli o komunikacji
> wifi, a nie zapomnieli o modbusie? E...

Najpierw zrobili falownik. Potem pewnie przydaloby sie zdalne
sterowanie, wiec zrobili RS-232, bo akurat bylo latwo.
Potem dolozyli modbusa, bo tez bylo latwo.
A teraz chcesz dolozyc ethernet, i juz jest trudno.
A nie - bardzo latwo, sa gotowe konwertery :-)

>> Dodaj, ze falownik zrobiles na procku, ktory dobrze faluje ... ale nie
>> ma ethernetu.
>> zmieniac procek czy dokladac interfejs?
>
> Pozbyś się iditycznej, lagującej wastwy modbusa? Nie mogę odczytywać
> parametrów falwonika częsciej "niż", ponieważ pod spodem jest gówniana
> transmisja szeregowa czuła na timeouty. XXI wiek, przypominam, na
> księżycu byliśmy podobno.

A w rakiecie pewnie gowniana transmisja szeregowa byla :-)

Przy czym wydaje mi sie, ze podniesc predkosc modbusa najprosciej,
patrz chocby na propozycje Piotra - szybkie i gotowe lacza LVDS.

Timeout ... przy braku bledow IMO nie przeszkadzaja w szybkosci.
A jak bledy sa, to i ethernet bedzie mial problem.

>> No to dolozyli, a ty sie pieklisz :-)
> Dołożyli protezę. Dzisiaj/jutro będa mi montować rekuperator. Zgadnij,
> jakie mają rozwizanie automatyki domowej w tym reku. Podpowiem, że
> standardowe dla XXIw w automatyce

A jaka masz "centrale" w tej automatyce domowej, i co potrafi :-)

>> Nie wystarczy wifi, teraz musi np wspolpracowac z chmura google :-)
>
> I współpracuje, nie myśl sobie. Przez modbus i translator na serwerze w
> chinach. Co prawda nie moja, ale mają taką opcję.

No ale trzeba bylo zrobic.
A tu zobacz - kto inny zrobil :-)

> A MQTT nie ma w ani jednym z urządzeń. Bo po co ma być użyteczne.

A co to ten MQTT ... taki modbus, tylko troche inny? :-)

A widze ... ale to przeznaczone do urzadzen o malej przepustowosci :-)

J.

do góry

On 27/04/2021 11:58, J.F wrote:
> Ty o zaletach sprzetowych

Watek wybranchował się do wypocin o sprzętowych zaletach magistrali
tokenring nad modbusem.

>, a ja o tym, ze sam ethernet to dopiero
> poczatek, potem trzeba jeszcze duzo oprogramowania.

Mówisz o tej ciezkiej pracy z okolicy użycia gotowej bibliteki ;) ?

>> 1) pseudo równoległość
>> 2) odpornośc na zakłucenia
> Hm, chyba podobna jak RS-485. Podobna technologia.

Równoległość na pewno nie. Podstawowym problemem z RS485 jest blokowanie
magistrali kiedy urządzenie ustala zeznania.

>> 3) wyższe warstwy gwarantują dostarczenie wiadomości
> No wlasnie - wyzsze warstwy. Jak sa.

Zawsze są. Nawet w tej najgorszej zabawce RS485<->ethernet jest normalny
TCP.

> Jak sa dobrze oprogramowane, zeby
> dostarczenie nastapilo w odpowiednim czasie.

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.

>> 4) automatyczny podziała pasma
> No, w switchach, czy jeszcze z kolizjami ?

Nie ma kolizji w normalnej sytuacji ethernetu na skrętce. Jest
dropowanie pakietów, jeśli osiągniesz pasmo dziurki, lub pasmo przełączania.

> Poza tym w automatyce zwykle nie masz klopotow z pasmem

To po co komu 3Mbity na node jako zastepnik modbusa?

Modbus nie ma grzechu w tym że powolny, tylko w kilku innych idityzmach,
jak w każdym standardzie projektowanym na kolanie.

> ... za to jak
> wrzucisz kilka "systemow" do jednej sieci ethernet, to sie moga
> pojawic :-)
> Choc switche separuja.

I robią to bardzo skutecznie.

>>> Musialbys go od golasa oprogramowac.
>> Nie, stosów od ethernetu po tcp jak mrówków.
> A owszem, ale to juz wybrales standard TCP/IP - i dobrze,
> ale to nadal malo - cos trzeba w ramach tego standardu :-)
> MODBUS po TCP/IP.

To jest zwykłe proxy bajt tcp do bajt po serial. I to jest *źle*, ale
tak to się robi b otaki jest "standard".

Napisanie własnego konwertera tcp<>modbus to, zgaduje, koło 100 linijek,
zakładając że mam gotowy stos tcp (a zazwyczaj mam).

> Ale z kolei TCP moze miec dlugi czas repetycji po bledzie.

Więc zdecyduj: pasmo czy responsywaność.

Dodatkowo ten "długi czas" brzmi jak mgnienie oka w porównaniu z
modbusowymi lagami.

> Moze lepiej Modbus/UDP ? :-)

Można. Ba, nawet powinno się tak, a nie po TCP.

>>> A wczesniej opracowac jakis standard, i starac sie, aby sie przyjal.
>> No i czekając na ten cud dalej uzywamy modbusa przebranego w ethernet.
> Powyzej nawet sie nie zajaknales nad czyms lepszym :-)

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.

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

Po stronie kontrolera w falowniku nie przypuszczam - to nowy produkt.

>>> I dostowac programy do tego.
>> Zgadza się. Problemem jest białko.
> Zaraz zaraz.
> Masz w fabryce troche maszyn i czujnikow modbus/RS-485, i zgrabne
> programy do zarzadzania tym wszystkim, i nagle chcesz powiedziec -
> rzucmy to w cholere, kupimy wszystko w nowej, lepszej technologii?

Nie. Ubolewam raczej nad "lepsza techonologia polega na wsadzeniu
modbusa w tcp i udawaniu że działa". Czyli kupujesz nową technologię ze
wszystkim wadami starej.

Jak Ci działa modbus to gites. W wątku przeraziło mnie, że ktoś
wykoncypował *NOWĄ* magistralę, która nie ma żadnych sensownych zalet
względem ethernetu.

> Te maszyny grube miliony kosztowaly, i moga jeszcze 10 lat chodzic :-)

A niech chodzą.

> A potem sie komus USB spodoba, a innemu Bluetooth - i wszystko
> kompletnie od nowa ?

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.

Ethernet wiele z tych głupot usuwa, ale nie jest standardem,
przynajmniej nie jest uważany za kandydata.

Powody histyczne, ale ileż można gadać że to wina Tus^M^M^M8051?

>>> A potem bys trafil na bariere komunikacji na wieksza odleglosc.
>> Internet nie działa?
> Internet dziala, ethernet nie.
> Wiec musisz od razu internet wybrac.

Nie. 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. Efektem czego automatycy drą ryja że się nie nadaje, bo
nie działa, a tak naprawdę bład jest po stronie konwertera, który używa
protokołu w sposób niezgodny z zamierzeniem i powielane jest to od
chińskich zabawek za 50zł po profesjonalne za grube tysiaki. Bo to
"standard przemysłowy z tektury i paździerza".

To takie minimum lokalne. Wszyscy siedzimy w tym szambie bo koszt
wyjścia za duży.

>> Patrz: ethernet za friko zapewnia dużą odległość,
>> choćby na światełku, przez radiolinie, po VPNy.
> No wlasnie - internet nie oznacza automatycznie Ethernetu :-)

Nie rozumiesz: jeśli zrobiłeś komunikacje po ethernecie i zrobiłeś
poprawnie (nie jak producenci konwerterów) to to czy po drodze ten
ethernet na chwile nie zamienia się w światełko lub karty perforowane,
leci przez chmurę w Kaliszu, nie jest istotne. Dostajesz ZA DARMO masę
bajerów, których nie dostaniesz w modbusie. W dodatku trywialnie się
skaluje, zarządza, modyfikuje.

>> Napisali od zera oprogramowanie do falownika. I zapomnieli o komunikacji
>> wifi, a nie zapomnieli o modbusie? E...
> Najpierw zrobili falownik. Potem pewnie przydaloby sie zdalne
> sterowanie, wiec zrobili RS-232, bo akurat bylo latwo.
> Potem dolozyli modbusa, bo tez bylo latwo.
> A teraz chcesz dolozyc ethernet, i juz jest trudno.
> A nie - bardzo latwo, sa gotowe konwertery :-)

Efekt: mają błąd w obsłudze TCP. Bo taki mają wszystkie gotowe
konwertery robiące za prosty proxy tcp<->serial.

Narzekam sobie nad badziewnością ogólną, bez konkretów rewolucyjnych.

>> Pozbyś się iditycznej, lagującej wastwy modbusa? Nie mogę odczytywać
>> parametrów falwonika częsciej "niż", ponieważ pod spodem jest gówniana
>> transmisja szeregowa czuła na timeouty. XXI wiek, przypominam, na
>> księżycu byliśmy podobno.
> 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.

> Przy czym wydaje mi sie, ze podniesc predkosc modbusa najprosciej,
> patrz chocby na propozycje Piotra - szybkie i gotowe lacza LVDS.

Problemem modbusa nie jest prędkość. To najmniejszy problem.

Ponadto ... LVDS ..... to nie jest nic poza opisaniem zjawisk fizycznych
w drutach. Do protokołu torche brakuje.

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

> A jak bledy sa, to i ethernet bedzie mial problem.

I je automagicznie poprawi, a warstwa troche powyżej gołych ramek nawet
ich nie zauważy apliakcja.

>> Dołożyli protezę. Dzisiaj/jutro będa mi montować rekuperator. Zgadnij,
>> jakie mają rozwizanie automatyki domowej w tym reku. Podpowiem, że
>> standardowe dla XXIw w automatyce
> A jaka masz "centrale" w tej automatyce domowej, i co potrafi :-)

Co chcę. W końcu to oprogramowanie dla programistów, wiec mogę zrobic w
tym wszystko. Ale tak, do wyboru będę miał RS485+modbus oraz, dodatkowo
jako szczyt profesjonalizmu, konwerter RS486 na wifi, oczywiscie z
błednym uzyciem TCP, bo to "standard".

>> A MQTT nie ma w ani jednym z urządzeń. Bo po co ma być użyteczne.
> A co to ten MQTT ... taki modbus, tylko troche inny? :-)

Nie. To jest istota wszelakich systemów automatyki domowej i nie tylko.
ma cechy których modbus nie ma jak zaimplementować, nie ta warstwa.

To problem białkowy. Na ten przykład Roomba implementuje MQTT. Nie
musieli patrzeć na badziewie w automatyce i nie mają modbusa. Skandal.

> A widze ... ale to przeznaczone do urzadzen o malej przepustowosci :-)

Nie chodzi o przepustowość, tylko o masę innych cech. Równoległośc,
pewność eventu, sekwencyjność, dowolne relacje N do N itd itp. Masa
tego. Modbus przy tym wygląda jak by projektował go przedszkolak po
ostrm piciu (soczku) w kanciapie.

do góry

On Tue, 27 Apr 2021 12:33:47 +0200, heby wrote:
> On 27/04/2021 11:58, J.F wrote:
>> Ty o zaletach sprzetowych
> Watek wybranchował się do wypocin o sprzętowych zaletach magistrali
> tokenring nad modbusem.

Hm, wydaje mi sie, ze TR nie widzialem w watku.
Chyba, ze od strony logicznej.

>>, a ja o tym, ze sam ethernet to dopiero
>> poczatek, potem trzeba jeszcze duzo oprogramowania.
> Mówisz o tej ciezkiej pracy z okolicy użycia gotowej bibliteki ;) ?

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

>>> 1) pseudo równoległość
>>> 2) odpornośc na zakłucenia
>> Hm, chyba podobna jak RS-485. Podobna technologia.
>
> Równoległość na pewno nie.

Ale odpornosc na zaklocenia elektryczne jakby podobna.

> Podstawowym problemem z RS485 jest blokowanie
> magistrali kiedy urządzenie ustala zeznania.

Ale to juz kwestia logicznej organizacji.
Mozesz sobie cos ala kolizje ethernecie zorganizowac,
mozesz Token Ring, mozesz wymagac szybkiej odpowiedzi.

>>> 3) wyższe warstwy gwarantują dostarczenie wiadomości
>> No wlasnie - wyzsze warstwy. Jak sa.
>
> Zawsze są. Nawet w tej najgorszej zabawce RS485<->ethernet jest normalny
> TCP.

Albo IPX, albo WfWG, albo Lantastik ... albo robisz sam i musisz sam
zrobic.

>> Jak sa dobrze oprogramowane, zeby
>> dostarczenie nastapilo w odpowiednim czasie.
>
> 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 jak jeszcze sa bledy mozliwe, to juz w ogole gwarancji nie ma.
Choc ze switchami powinno w miare szybko przejsc.

>>> 4) automatyczny podziała pasma
>> No, w switchach, czy jeszcze z kolizjami ?
>
> Nie ma kolizji w normalnej sytuacji ethernetu na skrętce. Jest
> dropowanie pakietów, jeśli osiągniesz pasmo dziurki, lub pasmo przełączania.

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

>>>> Musialbys go od golasa oprogramowac.
>>> Nie, stosów od ethernetu po tcp jak mrówków.
>> A owszem, ale to juz wybrales standard TCP/IP - i dobrze,
>> ale to nadal malo - cos trzeba w ramach tego standardu :-)
>> MODBUS po TCP/IP.
>
> To jest zwykłe proxy bajt tcp do bajt po serial. I to jest *źle*, ale
> tak to się robi b otaki jest "standard".
>
> Napisanie własnego konwertera tcp<>modbus to, zgaduje, koło 100 linijek,

Cos pisales o protokolach pisanych na kolanie :-)

> zakładając że mam gotowy stos tcp (a zazwyczaj mam).

Teraz. Oczywiscie po wyborze odpowiedniego procka.

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

A czemu ja?

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

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

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

>>>> A wczesniej opracowac jakis standard, i starac sie, aby sie przyjal.
>>> No i czekając na ten cud dalej uzywamy modbusa przebranego w ethernet.
>> Powyzej nawet sie nie zajaknales nad czyms lepszym :-)
>
> 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?

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

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

> Po stronie kontrolera w falowniku nie przypuszczam - to nowy produkt.

Nowy produkt ale ze starym Modbusem?
A jakby wymyslili wszystko na nowo, lepiej, to co z cala reszta - znow
dziobac od zera ?


> Jak Ci działa modbus to gites. W wątku przeraziło mnie, że ktoś
> wykoncypował *NOWĄ* magistralę, która nie ma żadnych sensownych zalet
> względem ethernetu.

I tu sie generalnie zgadzam.

>> Te maszyny grube miliony kosztowaly, i moga jeszcze 10 lat chodzic :-)
> A niech chodzą.

A informatyk zakladowy bedzie narzekal.
Albo i nie - u mnie wszystko dziala, a wy mi tu jakas nowa magistrale
proponujecie :-)

>> A potem sie komus USB spodoba, a innemu Bluetooth - i wszystko
>> kompletnie od nowa ?
>
> 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.

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

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

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

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

>>>> A potem bys trafil na bariere komunikacji na wieksza odleglosc.
>>> Internet nie działa?
>> Internet dziala, ethernet nie.
>> Wiec musisz od razu internet wybrac.
>
> Nie.

No ale chesz ten internet. Przynajmniej tak sie wydaje.

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

> Efektem czego automatycy drą ryja że się nie nadaje, bo

Ale co sie nie nadaje - VPN ?

> nie działa, a tak naprawdę bład jest po stronie konwertera, który używa
> protokołu w sposób niezgodny z zamierzeniem i powielane jest to od
> chińskich zabawek za 50zł po profesjonalne za grube tysiaki. Bo to
> "standard przemysłowy z tektury i paździerza".
>
> To takie minimum lokalne. Wszyscy siedzimy w tym szambie bo koszt
> wyjścia za duży.

O to to to :-)

Szambo ... ale nowe szambo za drogie :-)

>>> Patrz: ethernet za friko zapewnia dużą odległość,
>>> choćby na światełku, przez radiolinie, po VPNy.
>> No wlasnie - internet nie oznacza automatycznie Ethernetu :-)
>
> Nie rozumiesz: jeśli zrobiłeś komunikacje po ethernecie i zrobiłeś
> poprawnie (nie jak producenci konwerterów) to to czy po drodze ten
> ethernet na chwile nie zamienia się w światełko lub karty perforowane,
> leci przez chmurę w Kaliszu, nie jest istotne. Dostajesz ZA DARMO masę
> bajerów, których nie dostaniesz w modbusie. W dodatku trywialnie się
> skaluje, zarządza, modyfikuje.

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

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.

>>> Napisali od zera oprogramowanie do falownika. I zapomnieli o komunikacji
>>> wifi, a nie zapomnieli o modbusie? E...
>> Najpierw zrobili falownik. Potem pewnie przydaloby sie zdalne
>> sterowanie, wiec zrobili RS-232, bo akurat bylo latwo.
>> Potem dolozyli modbusa, bo tez bylo latwo.
>> A teraz chcesz dolozyc ethernet, i juz jest trudno.
>> A nie - bardzo latwo, sa gotowe konwertery :-)
>
> Efekt: mają błąd w obsłudze TCP. Bo taki mają wszystkie gotowe
> konwertery robiące za prosty proxy tcp<->serial.
> Narzekam sobie nad badziewnością ogólną, bez konkretów rewolucyjnych.

>>> Pozbyś się iditycznej, lagującej wastwy modbusa? Nie mogę odczytywać
>>> parametrów falwonika częsciej "niż", ponieważ pod spodem jest gówniana
>>> transmisja szeregowa czuła na timeouty. XXI wiek, przypominam, na
>>> księżycu byliśmy podobno.
>> 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.
I co teraz - bedziesz chwalil? :-)

>> Przy czym wydaje mi sie, ze podniesc predkosc modbusa najprosciej,
>> patrz chocby na propozycje Piotra - szybkie i gotowe lacza LVDS.
>
> Problemem modbusa nie jest prędkość. To najmniejszy problem.
>
> Ponadto ... LVDS ..... to nie jest nic poza opisaniem zjawisk fizycznych
> w drutach. Do protokołu torche brakuje.

Zdecydowanie, ale jak Piotr pisze - kolejna warstwe w FPGA ma gotową.

Czyli wychodzi z tego taki Ethernet.
Ale skoro nie ma zalet, to po co zmieniac na ten nowy :-(

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

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

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

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

>>> Dołożyli protezę. Dzisiaj/jutro będa mi montować rekuperator. Zgadnij,
>>> jakie mają rozwizanie automatyki domowej w tym reku. Podpowiem, że
>>> standardowe dla XXIw w automatyce
>> A jaka masz "centrale" w tej automatyce domowej, i co potrafi :-)
>
> Co chcę. W końcu to oprogramowanie dla programistów, wiec mogę zrobic w
> tym wszystko.

No widzisz - Ty i teraz robisz co chcesz.
Ale pewnie juz sa gotowe, obsluguja standardy X, Y, Z, nowy lepszy
bedzie sie musial przebic.

>>> A MQTT nie ma w ani jednym z urządzeń. Bo po co ma być użyteczne.
>> A co to ten MQTT ... taki modbus, tylko troche inny? :-)
>
> Nie. To jest istota wszelakich systemów automatyki domowej i nie tylko.
> ma cechy których modbus nie ma jak zaimplementować, nie ta warstwa.
>
> 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

>> A widze ... ale to przeznaczone do urzadzen o malej przepustowosci :-)
> Nie chodzi o przepustowość, tylko o masę innych cech. Równoległośc,
> pewność eventu, sekwencyjność, dowolne relacje N do N itd itp. Masa
> tego. Modbus przy tym wygląda jak by projektował go przedszkolak po
> ostrm piciu (soczku) w kanciapie.

Projektowali pewnie adekwatnie do czasu powstania.

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

J.

do góry

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

do góry