Automatyka rządzi się swoimi prawami. Większość z nas programuje w językach standardowych dla PLC jak drabinka, SFC, Funcion Block, ale czy właściwie musi? Czy myślicie, że świat informatyki i języki wysokopoziomowe kiedyś wejdą na dobre do przemysłu?
Chciałbym rozpocząć dyskusję na temat tego czy jest możliwe abyśmy programowali maszyny przemysłowe w np. w MS Visual Studio używając C++ czy Javy? Czy powinniśmy obawiać się, że programiści komputerowi nas “wygryzą” z zawodu? Czy może jednak Ladder Logic czy InTouch mają zalety których nie da się zastąpić?
Sam ostatnio nad tym się zastanawiałem. Z jednej strony wiele osób uważa, że pisanie w jezykach wyższego rzędu jest wygodniejsze. Jednak dla pracowników utrzymania ruchu to drabinka czy bloki funkcyjne są dużo bardziej przejrzyste do odczytu, kiedy czas nagli i jest to z całą pewnością ich ogromna zaleta.
1 polubienie
Moim zdaniem jest to coś czego nie przeskoczymy. Po mino aktualnej dominacji LAD/FBD prędzej czy później trzeba będzie zacząć pisać w językach wysokiego poziomu bo procesy staną się na tyle skomplikowane, że napisanie programu w LAD/FBD zrobi z kodu “sieczke”. Z drugiej strony pisanie w C++/C#/JAVA jest dużo wygodniejsze i IDE są dużo bardziej dopracowane.
W zasadzie coraz częściej sięgam po języki tekstowe podczas programowania PLC bo w niektórych sytuacjach są wygodniejsze a czasami nawet niezbędne. Chociażby podczas pracy na strukturach/tablicach
Wiadomo że nie wszystko da się zrobić w drabince. Osobę zlecającej wykonanie projektu mało interesuje jak tobie wygodniej się pisze - ma być tak aby służba utrzymania ruchu w prosty i szybki sposób ogarnęła gdzie jest problem. Ja pisząc programy, robiąc modyfikacje miałem często zalecenie od klienta - to co można ma być w drabince - taki standard.
Być może niedługo wejdą sterowniki w typie Next - gdzie wszystko będzie pisane w językach wysokopoziomowych. Będzie jednak to wymagało systemów eksperckich, które powiedzą ludkom z UR, gdzie jest problem i jak go usunąć bez kopania w kodzie.
2 polubienia
W drabince też obrabiałem tablice i używałem struktur - zmiennych uder define, własnych funkcji parametryzowanych które były wywoływane w drabince i pisane były w drabince.
Raczej chodzi mi o to ze sprawdzenie 1000 elementowej tablicy to w wysokopoziomowym języku 3 linijki. A nie jak w Ladzie 15 instrukcji w tym “JUMP” na widok ktorego dostaje palpitacji serca. Zreszta jeszcze nie spotkałem takiego programisty który by promował używania JUMPOW.
Czy informatycy nas wygryza? Raczej nie do końca. Należy pamiętać, że oprócz programowania musimy znać i rozumieć elektrotechnikę, układy sterowania, urządzenia współpracujące że sterownikami, protokoły komunikacyjne itd. Informatycy czesto nie posiadają nawet podstaw w tym zakresie.
Co innego gdy informatyk ma wsparcie Automatyka w zakresie tego czym sterownik będzie sterował. Nasi sąsiedzi, informatycy z krwi i kości nabrali dotacji z Unii na badania i rozwój innowacji. Świetnie programują a ich interfejsy to po prostu bajka. Niestety ich wiedza o sterowaniu jest mierna. Uparci jednak są, tu podpytają, tam doczytają i brną do przodu. Domykają projekty i ktoś później to odkupuje. Takich należy się bać 
2 polubienia
I tu z pomocą przychodzi też firma Phoenix Contact, która wypuszcza na rynek sterowniki PLCnext. Może do niego podejść każdy kto potrafi podpiąć się do sterownika z lapkiem, uruchomić software i zmodyfikować lub dopisać kod w dowolnym języku (w takim, którym potrafi i rozumie napisać kod).
Myślę, że informatycy raczej nie wygryzą Programistów-Automatyków z działów UR czy BM. Tak jak napisał @MarcinFaszczewski zbyt wiele rzeczy musieliby ogarnąć z zakresu elektrotechniki, pneumatyki, hydrauliki by zrozumieć idee sterowania w tych układach. Choć pewnie znajdzie się grono Informatyków, którzy wiedzą jak podejść do tematu
2 polubienia
Tez jestem zdania jak wyzej, ze informatycy za wiele musieliby ogarnac. Ale jesli ktos bedzie chcial to to zrobi, chociaż w sumie po co ? Zamienic prace zdalna z biura/domu na wyjazdy na uruchomienia ?? 
ostatnio nawet spotkalem sie z opinia wieloletniego programisty ze nie dalby sobie rady jako automatyk w UR, wszystko przez to ze musialby codziennie elastycznie podchodzic do problemow, szukac po manualach itd. Woli sie przygotowac do danego projektu i spedzic nad nim 2 miesiace ale pracujac tylko w tym.
Ja osobiście uważam, że elektrycy automatycy są nie do wygryzienia napisanie samego programu bez znajomości działania nie należy do łatwych, dodatkowo przy uruchomieniach zawsze wychodzą jakieś ale a wątpliwe by w takich sytuacjach poradził by sobie informatyk. Osobiście wygodnie mi pisać w drabince choć wiem ze od jeżyków wyższego stopnia nie ucieknę, a tak na koniec prędzej automatycy nauczą się programować jak informatyk nauczy automatyki
1 polubienie
Myślę, że mocno wynosicie na piedestał automatyka, jakoby posiadał wiedzę tajemną. Kwestia programowania większości maszyn to prosta i powtarzalna logika.
O wiele trudniejsze jest odpowiednie zaprojektowanie urządzenia od strony technologicznej niż oprogramowanie.
Języki wysokiego poziomu mają dużo plusów co do drabinki, nawet debugowanie jest prostsze, aczkolwiek są trudniejsze do zrozumienia na pierwszy rzut oka i drabinką tutaj wygrywa wizualizacją.
Prostota pojęcia i łatwość modyfikacji wygrywa i dlatego ladder jest najpopularniejszym językiem w przemyśle produkcyjnym.
Tak samo trudno jest automatykowi w IT jak programiście w automatyce
2 polubienia
Dokładnie - praca na tablicach / strukturach danych powinna być obowiązkowo implementowana w językach do tego przeznaczonych. Co więcej, dla programisty integratora większość instrukcji o wiele prościej i szybciej zaimplementować w językach wyższego poziomu (moim zdaniem) - diagnostyka takiego kodu (nawet dla samego integratora) to już niezależna kwestia.
Uwzględniając w tym dział UR złotym sposobem wydaje się podejście hybrydowe - wypracowywanie pozwoleń, proste sterowanie powinno pozostać zaimplementowane w języku LD, a złożone operacje i przetwarzanie danych w języku ST.
Osobiście uważam, że świat automatyki jest światem pełnym kompromisów i zawsze staramy (a przynajmniej powinniśmy) przygotowywać aplikacje z myślą o innych użytkownikach tego kodu.
Uważam identycznie - znajomi pracujący w branży IT mają już problem z nadążaniem za bieżącymi trendami, a zmieniają się one w niesamowitym tempie. Sam wachlarz technologii dotyczących aplikacji Web, które są teraz tak popularne jest ogromny. Samo przebranżowienie się do IT to nie tak prosty proces, jakby się mogło wydawać. Temat zmiany branży z IT na automatyka został już chyba wyczerpany 
1 polubienie