Procesor za -10 złotych. :)

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>

Wnikaja.

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

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

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

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

J.

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

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.

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.

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.

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.

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

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

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

ftp://212.85.113.169/Instrukcje_obslugi/Instrukcje%20obslugi%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.

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" ;)

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

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.

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

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

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

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

Zgadza się. Problemem jest białko.

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

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

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

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.

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.

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.

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.

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

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

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

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.

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

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.

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 ?

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

No wlasnie - internet nie oznacza automatycznie Ethernetu :-)

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

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

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.

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

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

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

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

J.

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

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

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

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

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.

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

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.

I robią to bardzo skutecznie.

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

Więc zdecyduj: pasmo czy responsywaność.

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

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

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.

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.

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.

A niech chodzą.

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?

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.

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.

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.

Ale za to system operacyjny z wywłaszczaniem i projektowany nie na kacu. Nie do ogarnięcia na 8051 do dzisiaj.

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.

Przeszkadza zasadniczo, bo nie możesz multiplexować wielu transmisji na jednym kablu *jednocześnie*. W ethernecie możesz.

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

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

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.

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.

Może i dobrze. Jestem w stanie sobie wyobrazić jaka skala dziur czy nawet braku jakiekolwiek ACL byłaby w takich przemysłowych urządzeniach. Z dużym prawdopodobieństwem taki "bardzo ważny szkielet sieci produkcyjnej" często stykał by się (przez przypadek lub nie) mniej lub bardziej z publiczną siecią i dopiero byłyby cyrki. Potem producenci by musieli lataćb te dziury (a tego nie lubią) np. w tokarce, bo jakiś "haker" przerpogramował i operatorowi łapy urwało. Tak dzięki takiemu modbusowi or co. mają jakąś tam separację technologiczną....

Wystaw sobie dowolny (nawet świeżo uzyskany z IANA) IP i monitoruj na interfejsie co do niego przychodzi, przecież to już obłęd jakiś. Skaner skanera skanerem pogania. Tego w latach 90 nie było.

Powyższego nie chwytam. Po co blokować magistralę?? Urządzenie (node) czytające temperaturę czegoś tam może nawet czytać ją raz na dobę, a masterowi zwrócić natychmiast ostatni pomiar jak pyta (nie ważne kiedy zrobiony). To logika mastera ma wiedzieć czy to pomiar aktualny czy nie.

Miałem (niemiecki, a i owszem) miernik izolacji, sterowany modbusem, tyle że przez RS232. Taki do badania izolacji na lini produkcyjnej ręcznie. Dotyka się sondą obudowę i nastepny.

Całkiem spoko. Ustawiasz parametry, wysyłasz coś do rejestru i strzela napięciem, potem czytasz wynik, ładnie zautomatyzowane i bangla.

Wszystko super, do momentu kiedy dłubie przy sofcie sterującym i nieopacznie wysyłam 4 do rejestru który przyjmuje 0-3. Zawiesił się. Pomyslałem sobie że nie mozna być aż takim idiota, ale ... trzeba sprawdzić.

Po godzinie wiedzialem jak go posmerać po modbusie, coby generował na stałe setki V na próbniku (normalnie odpalanym tylko na milisekundy). Wystarczyło do rejestru określającego czas w ms wysłać wartośc ujemną (w U2)... natomiast dodatnie grzecznie ograniczał do bezpiecznych ;) W efekcie miernik migał czerwonym światełkiem, przestawiał kolor na zielony i można było razić ludzi sondą pod napięciem.

Morał z tego taki że znacznie bardziej przerażają mnie idioci w embedded od modbusów robiący wszystko od zera na 8051 sami, niż ludzie biorący gotowe webservery z prostym api, stosowane w embedded i przetestowane juz przez kogoś.

PS. Historia ma również zakończenie: po zgłoszeniu w firmie buga dostałem zwrotnie skan kartki z zakreślonym na czerwono opisem, że akceptowane są tylko dodatnie wartości. I duży, czerwony wykrzyknik obok. Prawdopodobnie cobym następnym razem nie robił z siebie idioty. Po niemiecku nie umiem, więc pokazali mi obrazkowo gdzie moje miejsce.

To już problem infrastruktury, higienty i białka. Wirówki w Iranie zupełnie się nie stykały z internetem i padły.

Nic nie pomaga. Do tych modbusów są podpięte dziurawe sterowniki, często z absurdalnie niskimi poziomami zabezpieczeń. Co z tego że dziura jest po drugiej stronie modbusa. Dziura to dziura.

Nie wiem co sie stanie, jak zacznę grzebać po moim falownieku, po nielegalnych wartosciach rejestrów. Może nic, a może wybuchnie.

Ale jest dzisiaj i wiemy jak się przed tym chronić. Napisanie prostego webapi bez bugów jest w zasięgu przeciętnego programisty, byle by świadomego.

To inna warstwa latency.

Ja mówie o przypadku: wysyaasz "daj temperaturę". I czekasz na odpowiedź, choćby ACK, bo soft po drugiejs stronie jest powolny. To czy ktos sobie temperaturę buforuje nie ma znaczenia, modbus po prostu wymusza czekanie aż ktoś łaskawie ruszy tyłek po drugiej stronei i odpowie.

W międzyczasie mogło by iśc wiele więcej ramek do innych czujników, ale nie może.

Teraz wyobraźmy sobie sytuację że Pani Halinka potknęła się o kabel od czujnika.

Ile poczekamy? I dlaczego to blokuje magistralę?

Ethernet nie blokuje, natomiast moze blokować *software* i to w dodatku tylko w kontekście tego jednego odczytu, reszta sobie bangla jak gdyby Pani Halinki nie było.

No ale jeśli to ACK jest w marginesie czasu przewidywanego na ACK w _konkretnej_ implementacji jakiegoś protokołu (np. modbus) to chyba nie jest problem, bo tak ma być. No chyba nie oczekujesz, że protokół opracowany do komunikacji (będący z jego natury wolnym) w trakcie przepisowego oczekiwania na odpowiedź mógłby robić coś innego. Ale oczywiście to co z natury jest wolne (z założeń) można jeszcze bardziej spowolnić przez błędy implementacyjne.

Ależ to przecież standard. Jest ciągle poza wyobraźnią ewentualna możliwość zadawania wartości z poza oczekiwanego zakresu (choć osobiście uważam, to jedynie gra w udawanie głupka niż faktyczny brak wyobraźni z konsekwencji takich bugów). Pytanie co wtedy, gdy faktycznie komuś się stanie krzywda z tego powodu i zacznie się komunikacja z taką firmą nie od strony działu "support" ale "legal" z odpowiednią gęstością prawników/M2.

To tylko tym gorzej dla nich, że nawet punktu styku z siecią nie potrzeba.

No ale tu nie o sam fakt zjawiska tylko o jego skalę chodzi.

Czekasz, ale na wolnym laczu to niewiele. Bo jeden bajt transmisji pozwala na rozpoczecie odpowiedzi.

a przy szybkiej ... czekanie mniej doskwiera, chyba, ze naprawde potrzebujesz danych szybko :-)

No ale ... skoro rozwiazaniem jest switch ethernet, to moze zrobic switch modbus :-)

To faktycznie moze byc problem.

Bo taka koncepcja. Do tej pory sie sprawdzala.

Taa, tylko czy ten software w calosci dobrze zadziala ...

J.

Ten czas zwyczajowo jest bardzo długi. Być może dało by radę wysłać dodatkowe ramki do innych urządzeń. O ike niektóe urządenia modbusowe potrafią odpowiedzieć prawie natychmiast, to nie jest to zasada.

Mógłby. Ethernet robi.

I tak jest. Jak mówie "latency 20s" to przesadzam ale niewiele. Jeden z liczników energii jako obczajałem zwaracał wynik natychmiast albo po sekundzie. Eksperymentowałem i mozliwe że ma to zwiazak z "zapisywaniem flasha z licznikiem energii" kiedy jest zbyt zajęty sleep(1000), bo lagi pojawiały się periodycznie co minutę. Czyli już dupa, bo sekunda na magistrali 57600 to jest jednak kilka ramek do innych, któe nie dojdą. Jak masz jeden licznik, to nie problem ,ale jak pracuje ich kilka, to dramat. I winę ponosi producent licznika, ale tak naprawdę winę ponosi dziadostwo modbusa.

Lepiej switch ethernet z konwerterami do modbus na każdym porcie. Lepiej używać prządnej, przetestowanej technologii, a najlepiej ich stacku.

Niezupełnie. To się zwyczajowo kończyło: "no ale nie da się inaczej" i relaksacją parametrów.

To tak, jak ja: szukam licznika energii z odczytem co kilka sekund minimum, najlepiej kilka razy na sekundę. I jest z tym kłopot. "Bo Panie, komu to potrzebne".

Brak możliwosci generuje brak potrzeb, a one generują brak możliwości. W efekcie większośc liczników energii zamiast jakiejkowleik magistrali ma migającą diodę psu na budę potrzebną.

Robimy to od bardzo dawna i potrafimy ogarniać tysiace strumieni jednocześnie na komputerach z oprogramowaniem pisanym przez pryszczatych nastolatków. Tak, dajemy radę. Jak mówie, bardziej boje się o Heńka, co od 40 lat projektuje urządzenia na 8051 za każdym razem robiac kwadratowe koło w asm, bo tak najszybciej.

A narzekasz, jak wsadzili konwerter do maszyny :-)

Ale zachwycasz sie mozliwosciami Ethernetu - zrob tak samo na RS :-)

A owszem, ale ... moze licznik nie do tego sluzy.

za to te diodke mozesz prosto wykorzystac. W odroznieniu od kombinowania z magistrala.

Ale przeciez sa i lepsze

Nie gwarantuje, ze da sie szybko/czesto odczytywac, ani ... ile to kosztuje :-)

I po co to panie komus taki drogi licznik ... zaplaci przeciez tyle, ile zaplaci, nic mniej :-)

P.S. czemu taki maly prad ?

Te nastolatki niekoniecznie tak powiazane rzeczy tworza.

Takie rzeczy tworza ... dziadki-automatycy :-P

J.

Alez dojda. Tylko pozniej. Pytanie, na ile to istotne.

I tak, i nie.

Zobacz, jak to osiagnieto w ethernecie. Najpierw byla magistrala i kolizje.

Teraz masz lacznosc P2P i koncentratory-bufory (switche).

Gdyby to wdrozyc w 1979 ... za drogie, czy nie bardzo - wszak urzadzenia przemyslowe zawsze byly drogie? Ale co chcesz - licznik energii z pecetem do komunikacji ? :-)

Przy czym proponujesz tu jeszcze komunikacje asynchroniczna od strony logicznej ... czyli kolejne utrudnienia.

Owszem - mozna by juz przejsc na cos lepszego ... ale moze po prostu modbus jest dobry i tani - nikomu nie przeszkadzaja te minuty w odczycie licznikow pradu, a jak komus gdzies przeszkadza ... moze sobie kupic lepsze urzadzenia, ktore odpowiedza w 10ms ..

J.

I sam chip kosztuje ze cztery razy więcej niż moje całe urządzenie, pomijając drobiazg, że to jest duże BGA wymagające tak na oko z 8-10 warstw PCB i żre dużo prądu. Ale poza tym też dałby radę. ;)

Pozdrawiam, Piotr