On Tue, 27 Apr 2021 12:33:47 +0200, heby <h...@p...onet.pl> wrote:
> 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.

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.

--
Marek

do góry

On Tue, 27 Apr 2021 11:02:33 +0200, heby <h...@p...onet.pl> wrote:
> > 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.

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.

--
Marek

do góry

On 27/04/2021 14:18, Marek wrote:
>> 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.
> 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.

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.

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

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

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

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.

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

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.

do góry

On 27/04/2021 14:25, Marek wrote:
>> > 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.
> 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.

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.

do góry

On Tue, 27 Apr 2021 14:50:09 +0200, heby <h...@p...onet.pl> wrote:
> 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.

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.

--
Marek

do góry

On Tue, 27 Apr 2021 14:46:21 +0200, heby <h...@p...onet.pl> wrote:
> 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.

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 już problem infrastruktury, higienty i białka. Wirówki w Iranie
> zupełnie się nie stykały z internetem i padły.

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



> Ale jest dzisiaj i wiemy jak się przed tym chronić.

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

--
Marek

do góry

On Tue, 27 Apr 2021 14:50:09 +0200, heby wrote:
> On 27/04/2021 14:25, Marek wrote:
>>> > 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.
>> 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.
>
> 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.

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

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

To faktycznie moze byc problem.

>I dlaczego to blokuje magistralę?

Bo taka koncepcja. Do tej pory sie sprawdzala.

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

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

J.

do góry

On 27/04/2021 16:28, Marek wrote:
> 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ć.

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.

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

Mógłby. Ethernet robi.

> Ale oczywiście to co z natury jest wolne (z założeń) można jeszcze
> bardziej spowolnić przez błędy implementacyjne.

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.

do góry

On 27/04/2021 16:40, J.F wrote:
> No ale ... skoro rozwiazaniem jest switch ethernet, to moze zrobic
> switch modbus :-)

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

>> I dlaczego to blokuje magistralę?
> Bo taka koncepcja. Do tej pory sie sprawdzala.

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

>> 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.
> Taa, tylko czy ten software w calosci dobrze zadziala ...

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.

do góry

On Tue, 27 Apr 2021 16:57:50 +0200, heby wrote:
> On 27/04/2021 16:40, J.F wrote:
>> No ale ... skoro rozwiazaniem jest switch ethernet, to moze zrobic
>> switch modbus :-)
>
> Lepiej switch ethernet z konwerterami do modbus na każdym porcie. Lepiej
> używać prządnej, przetestowanej technologii, a najlepiej ich stacku.

A narzekasz, jak wsadzili konwerter do maszyny :-)

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

>>> I dlaczego to blokuje magistralę?
>> Bo taka koncepcja. Do tej pory sie sprawdzala.
>
> 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

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

> efekcie większośc liczników energii zamiast jakiejkowleik magistrali ma
> migającą diodę psu na budę potrzebną.

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

Ale przeciez sa i lepsze
http://www.apator.com/pl/oferta/pomiar-energii-elekt
rycznej/liczniki-energii-elektrycznej/liczniki-smart
/smartesox-pro

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 ?


>>> 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.
>> Taa, tylko czy ten software w calosci dobrze zadziala ...
>
> Robimy to od bardzo dawna i potrafimy ogarniać tysiace strumieni
> jednocześnie na komputerach z oprogramowaniem pisanym przez pryszczatych
> nastolatków. Tak, dajemy radę.

Te nastolatki niekoniecznie tak powiazane rzeczy tworza.

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

J.

do góry