Po ostatnim tygodniu uleję sobie troszeczkę na okolice pracy, czyli jak zwykle, nudna automatyka przemysłowa itp.
W komplecie do zagadnień poruszanych w notce
o ogólnie zbędnym przekombinowaniu nowożytnego IT, więc i automatyki, (znowu) ponarzekam na trochę bardziej szczegółowy temat, czyli łączności i networking w automatyce. Gdyż jakiś czas temu, w dyskusji w pracy ustaliliśmy, że problemy łączności i osieciowania wszystkiego zajmują nam jakieś 40-80% czasu pracy w nieco bardziej skomplikowanych projektach. 40% to jeśli dostawcy komponentów i ich łączności nie są totalnymi zjebami a nasz klient głupi, bo w marketingowe ściemy sprzedawców tych komponentów uwierzył. 80% to jeśli klient się upiera, że jakiś feature "ma działać", a dostawca akurat się poślizgnął na mydle i np. spierdolił firmware czegoś tam. Aż po ekstrema, że po prostu coś tam nie zadziałało i nigdy dobrze nie zadziała, bo nikt się nie przyzna, że/dlaczego nie działa, gdyż musiałby wymienić tysiące urządzeń albo płacić kary umowne, które by go zniszczyły; a do sądu jednak nikt nie pójdzie dla "drobiazgów", co najwyżej nigdy już nie będzie współpracował z bogu ducha winnym integratorem.
W poprzednim polskim życiu, na etacie automatyka raczej utrzymania ruchu niż projektów-integracji, oczywiście ocierałem się o pogłębiające się popier... coraz nowocześniejszych łączności elementów automatyki, w każdej nowszej maszynie i projekcie, ale były to jednak odpryski, no i powiedzmy 10 lat temu zaczynało być coraz "zabawniej", ale jeszcze daleko było do roku 2018. Chociaż jak się widziało ludzi naprawdę kumatych, starzejących się jakby tygodnie to były lata, nad projektami dla mnie, to trochę było nieswojo i czułem się z tym źle. Np. wizytujemy dostawcę trudnej maszyny, jak tam postęp, czy wszystko tiptop i w harmonogramie, bo zostało ze dwa tyg. do odbioru, a tam główny automatyk, kumaty gość, wygląda na nieco wymiętego i "przepalonego" papieroskami JESZCZE bardziej niż zwykle, "Panie X, pan wygląda na zmęczonego nad tymi naszym sterowaniem i programami... a mówiłem, to są trudne zagadnienia pomiaru i kontroli ciśnień i temperatur... - (zmęcz) panie Boni, jakie ciśnienia, jakie temperatury, widzi pan tę stertę (na biurku hałda podręczników wiodącego dostawcy niemieckiej automatyki na literę S, na oko w sumie 2000 stron) - Widzę - No, a ja to muszę chyba przeczytać jeszcze raz, bo to ich za przeproszeniem pokurwione OPC nie chce działać i nikt nie wie dlaczego, ich serwis też nie - No sorki, ale sami zechcieliście wsadzić OPC, mówiłem, że nie potrzebuję tego i wolę proste rozwiązania - Wiem. Teraz żałujemy.".
W obecnym życiu, integratora automatyki i okolic, zrobiło się od razu zabawniej. Bo komponenty i dostawcy nie są z krótkiej sensowej listy jak poprzednio, ale "nasz per klient nasz per pan", już pomijając, że w większości to są zaszłości historyczne (kto kupował masowo rozwiązania Siemensa czy Schneidera przez poprzednie 20 lat, nie przeskoczy z łatwością na Rockwella czy GE, itd), albo korporacyjne (komu globalne korpo wymusza dostawców i deal na komponenty i rozwiązania, nie ma lokalnie nic do gadania, choćby się waliło i paliło, musi się stan zawalenia i zapalenia przebić w górę na decyzyjny poziom korpo, odbić od marketingu i purchaserów "ale przecież taki dobry deal załatwiliśmy" i już 5 lat później może się coś zmieni; w wersji jeszcze zabawniejszej - zmienia go z dnia na dzień nowy właściciel korpo, czasem na dobre, czasem na zło, piekło i szatani, ale nadal: miniony w moim zasięgu mają niewiele do gadania).
Nagle okazało się to, o czym nie raz pisałem, że rozwiązania wielkich i solidnych dostawców automatyki nie kwalifikują się w ogóle do kulturalnego omawiania, tylko do obrzucenia przekleństwami i koktajlami Mołotowa. Że wyjęty z pudełka kosztowny sterownik PLC nie współpracuje z żadnym programem do jego obsługi, tylko trzeba mu najpierw spatchować firmware. Że kosztowne panele operatorskie "out of the box" są czyste jak kartka papieru i trzeba im wgrać WSZYSTKO zanim się zabierze za jakiekolwiek programowanie. Itd itp.
I to postępuje, do postępującej komplikacji coraz gorszych środowisk, pisanych w javie i podlanych pomysłami Microsoftu, dochodzi coraz większy burdel miotających się dostawców i ich developerów. Na czym spędziłem większość poprzedniego tygodnia - pozornie trywialny sprzęt, wiodącego amerykańskiego dostawcy na literę R, sterownik modułowy (PLC) z ich średniej półki, niewiele wejść wyjść, plus ich panel operatorski (HMI), też ze średniej półki. Trywialność, poza tym, że klient ma stary obiekt (bo to jest ogólnie retrofit, głównie elektryki i napędów, i przy okazji - PLC+HMI) z siecią DeviceNet, takim zabytkiem osieciowania przemysłowego sprzed zaorania wszystkiego przez Ethernet przemysłowy, więc PLC dostał moduł do komunikacji z tymże DeviceNetem.
Na dzień dobry, do zabawy z tym wszystkim potrzebne są pointegrowane w ch... środowiska i programy do developerki (posplatane ze sobą na max, bo dostawca R ma na to wyraźnie tradycyjnego zajoba od lat, żeby wszystko się zazębiało ze wszystkim), całość kosztuje bez upustów coś ponad 2000 funtów w wersji "druga od dołu, może coś się uda zaprogramować". A "pod spodem" pakietów developerskich leży znany potwór - kombajn firmy R. do komunikacji wszystkiego ze wszystkim we wszystkie strony. W założeniach, żeby było łatwiej, plug and play (prawie) i wszystko w jednym miejscu. W praktyce, działa "przeważnie", a jak nie, albo coś dziwnego jest do podłączenia, robi się "ni do rymu ni do sensu wyjmij gówno spod kredensu".
No ale za to mi płacą, żeby takie spierdoliny ogarniał, i ma się te doświadczenie z produkcjami firmy R., więc byłem dobrej myśli. Oraz komunikacja po USB do sterownika PLC zagadała "plug and play", jak powinna - aplauz i gratulacje (tu patrzymy znacząco na przykład na wiodącego francuskiego dostawcę na literę Sch., któremu jak się sterowniki USB sypnęły po wejściu win10, tak z pół roku wpierali wszystkim, że to przecież nie ich wina i "a u mnie działa"). I była to chyba jedyna rzecz w komunikacji tych 2-3 prostych pudełek, która zadziałała jak powinna...
Po dokopaniu się do modułu DeviceNet, okazało się, że programuje się go wyłącznie kolejnym pakietem firmy R. takim "do sieci" a nie "do komunikacji", cena w detalu jakieś 1100 funtów, nieplanowanych w projekcie. No dobra, zostałem wynalazcą i wynalazłem tenże pakiet, jak Iwan rower ("u Niemca na strychu"). Okazało się, że to co wynalazłem, nie czyta konfiguracji i plików od klienta (ale na to narzekaliśmy poprzednim razem) i w ogóle, tak jak pamiętałem, jest to masakryczne narzędzie. Ale powiedzmy, po krótkiej walce moduł podsieci DeviceNet zaprogramowałem, tudzież będzie czym go dopieszczać "na odbiorze".
Po dokopaniu się do konfiguracji wbudowanego w PLC Ethernetu (ma być do połączenia PLC-HMI), okazało się, że wszystkie opcje są "grayed" czyli przyblokowane, nawet podstawowe jak adres IP itp. ale nie ma w związku z tym żadnych błędów czy ostrzeżeń. Przyszło pogrzebać w grubaśnej dokumentacji, która usłużnie poinformowała, że albo PLC ma jakiś błąd (nie ma i łatwo to sprawdzić) albo ja nie mam odpowiednich uprawnień do tych operacji (no shit Sherlocku, tylko że to, czy mam czy nie mam uprawnienia i jak to sprawdzić, w trójkącie Windows - developerka - łączności, to temat na doktorat co najmniej).
Na szczęście przypomniałem sobie podobną akcję z innymi starszymi łącznościami dostawcy R. i zacząłem grzebać w kombajnie łącznościowym "pod" narzędziami developerskimi. Jak już się przebiłem przez zylion "drzew" i ich nodów, udało mi się znaleźć praktycznie te same opcje do Ethernetu, jak w pakiecie developerskim, tylko, co za niespodzianka, działające jak złoto i "panie, jakie blokady czy "grayed", tu wszystko działa". Superos, punkt odhaczony, mamy Ethernet. Wróć, mamy jeden koniec Ethernetu.
Przyszło przejść do panelu HMI, klasy 6 cali i średnia półka, takie coś jak nawigacja samochodowa sprzed dekady. Na dzień dobry panel obrzucił mnie nieprzyjaznymi konfiguracjami i ustawieniami (obligatoryjne hasła klasy jak do waszego banku przez internet, pytania pomocnicze do haseł) i całą tą nowomodna spierdoliną, jeszcze niedawno niespotykaną w byle HMI. No ale bystrze wyczaiłem, że chodzi to na WinCE z poprzedniej epoki, więc jest to HMI niepełnosprawne, a istotom ograniczonym umysłowo wiele się wybacza.
Jednakowoż, po ustawieniu wszystkiego do pionu,okazało się, że żadnej łączności ni ma. A dla ustalenia uwagi HMI ma bogato, jeden Ethernet i dwa porty USB. Po kolejnej "chwili" z dokumentacją okazało się, że port USB B jest atrapą (serio, ta budżetowa wersja HMI nie obsługuje go), a port USB A jest w zasadzie pendrive itp. jedyna "prawdziwa" opcja to ethernet. No dobra, wrzuciłem na próbę aplikację robioną wcześniej na ten HMI przez pendrajwa. Nie wstała. Gdyż developerka produkuje defaultowo appkę w wersji 10.0 a panel "out of the box" jest w wersji 9.0. Dlaczemu tak? bo ponieważ (ew. panel ze starej półki). A skądinąd firma R. uwielbia spieprzyć kompatybilność wersji hardware, software i chujware, daje do tego zylion opcji i "ułatwień", a i tak bywają fakapy, że o matko, rok temu na obiekcie mieliśmy dokładnie takie jazdy, z wersjami hard i soft różniącymi się na 2 miejscu po przecinku... Ookej, downgrade do 9.0 poproszę, appka nawet w końcu wstała, oklaski. W ramach testów, ustawiłem se wszystko z autostartem, naszym logo itp. Wydaje się, że działa. Tyle, że przestało pokazywać konfigurację panela. Oj, ja głupia nimfomanka, zachciało mi się testów.
Przyszło na serio wgłębić się w dokumentację. Okazało się, że firma R. kiedyś zapomniała, że jak się na serio serio ustawi appkę do autostartu i z blokadami operatorskimi (żeby ktoś do Win nie wyszedł) itd. w takim HMI, no to już się tego nijak nie ominie. Potem im przypomniano, że jest spierdolina (bo ludzie musieli np. rozbierać HMI, wyciągać z niego wewnętrzną pamięć w formie karty CF, znaleźć gdzieś czytnik CF, wyczyścić kartę, itp. zabawy. Przy HMI za tysiąc albo i dwa funtów.). Więc w R. dodali taki super tajny myk, że przez dwie sekundy przy bootowaniu pokazywał się biały "klawisz" w kącie ekranu, pozwalający wejść w konfigurację. Co oczywiście nasunęło kwestię, że jest spierdolina, bo na cholerę te wszystkie hasła i blokady, jak byle małpa może nacisnąć to białe i zaraz ominąć wszelkie zabezpieczenia. Więc w "mojej" aktualnej wersji, znowu nie ma żadnego wejścia w konfigurację, ale tak naprawdę jest (polecam odstawić napoje) - trzeba podłączyć zwykłą klawiaturę od PC po USB, napier... w odpowiedni klawisz przy bootowaniu, i wtedy pokazuje się z powrotem biały tajny "klawisz" konfiguracji... Zapamiętać - zabrać na uruchomienie klawiaturę USB.
Po wyczyszczeniu i ustawieniu wszystkiego w HMI z ethernetem, okazało się, że może i jest git, ale od strony programu developerskiego na moim PC nie jest. Znaczy, nie widzi on wskazanego IP, ethernetu itp. Niby było to do ominięcia, bo mógłbym przewalać zrobioną tymże programem appkę przez pendrive, ale to trochę niewygodne, i jak zwierzę. Więc zacząłem drążyć, na szczęście i fuksem względnie szybko się zorientowałem, że ktoś mnie tu robi w wała - w programie developerskim ładnie pokazano kawałek "drzewa" komunikacji i hierarchię jej nodów (do HMI trywialnie krótką), w "kombajnie" do komunikacji widać to samo; ale nagle się zorientowałem, że kiedy w "kombajnie" do komunikacji coś tam ręcznie zmieniam, np. kasuję, to w developerce nic się nie zmienia...
Okazało się, że to są dwa różne drzwka, wyglądające "tak samo", pod spodem chodzą obecnie DWA kombajny do komunikacji, stary i nowy. Developerka PLC używa obu, ale domyślnie raczej starego, a developerka HMI raczej tylko nowego... Niezmierzone są głębie mądrości firmy R.! (tutaj se można obejrzeć eksponaty, czyli
trzy programy, których potrzebuję, żeby ogarnąć żałośnie prosty projekt...)
I to by było na tyle. I nie było to BARDZO zło i szatani, o, daleko do tego - nic tu nie chodziło przez chmurę (jak u wiodącego dostawcy G.), nie miało spier... firmware (jak w paru przypadkach ostatnimi laty), nie wymagało patchowania "na dzień dobry", prawą nogą przez lewe ramię (jak u wielu). Raczej był to standard.
Morałów jest kilka, poza "70% pier...my się z komunikacją, 15% z klientem, 5% z dokumentacją, na programowanie mamy pozostałe 10%".
Np. jeszcze 15 lat temu uważano, i sam lansowałem tezę, że dobry fachowiec to taki, który zna się na automatyce, różnych PLC, SCADA, HMI itp. i na procesach przemysłowych, a właściwej deweloperki konkretnego dostawcy nauczy się w locie. No więc obecnie nie nauczy się w locie, bo jest to nauka jazdy po polu minowym, i dla w miarę kompletnej oferty takiej przykładowej firmy R. (czy podobnych) nawet doświadczony ogólnie gość, ale niedoświadczony z AKTUALNYMI fakapami firmy R., na oko potrzebowałby miesięcy i paru projektów. Więc możliwe są bardzo malownicze frustracji i porażki.
Inny morał jest taki, że wszystkie te łączności są znacznie gorsze niż też UPIERDLIWE (ale inaczej) łączności z poprzedniej epoki i po 20 latach obiecanek "plug and play", otwartych rozwiązań, przyjaznej kompatybilności, itd. wiodący dostawcy nawet nie są w pobliżu rozwiązań i dobrej praktyki DOBRYCH dostawców sprzed 15 lat. Co smutne i frustrujące.
Ale rewolucji nie będzie, to nie są miliony sfrustrowanych klientów, którzy pójdą gdzieś indziej. To nie smartfon, że jak ci się krzaczy, jest niekompatybilny z czymkolwiek, wifi się wiesza, itd. to kupisz inny od innego dostawcy. Tu nie ma tak łatwo i tanio, a i o lepszych dostawców coraz trudniej.