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.