Elektroda.pl
Elektroda.pl
X
Elektroda.pl
IGE-XAOIGE-XAO
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Pobieranie danych z maszyn

19 Nov 2017 14:43 756 8
  • Level 10  
    Witam

    Chciałem wypytać kogoś z większym doświadczeniem jakie mam możliwości wyciągania danych z urządzenia do systemu monitoringu, powiedzmy, że MES.
    Z własnego doświadczenia widzę 3 sposoby:
    Sposób 1. Podłączając się do sterownika urządzenia i przesyłanie danych z tego sterownika do mojego dodatkowego i za jego pomocą przesyłanie do bazy danych. Niemniej tutaj pewnie potrzebuje dostępu do programu sterownika w maszynie, bo jak inaczej mam jakiekolwiek dane przesłać?
    Sposób 2. Zainstalowanie dodatkowych czujników na maszynie, które będą połączone tylko do sterownika systemu MES i w ten sposób monitorowanie jej aktualnego statusu.
    Sposób 3. Jeśli nie ma możliwości ani na pierwsze ani na drugie, to można jeszcze zainstalować przekaźniki półprzewodnikowe z małym prądem załączania (ok 8mA) i za jego pomocą "kopiować" sygnały z urządzenia. Moim zdanie przekaźnik nie powinien zakłócać pracy nawet jeśli podłącze do na wyjście sterownika równolegle, czy na wyjście z czujnika krańcowego (wejście sterownika).

    Pytanie czy dobrze myślę, no i czy ewentualnie jest jeszcze jakiś sposób z którego ktoś korzystał i się sprawdził?
    Wiadomo, chodzi też o odizolowanie jednego układu od drugiego.

    Z góry dzięki za odpowiedzi.
    Pozdrawiam
  • IGE-XAOIGE-XAO
  • Automation specialist
    Jakie parametry chcesz monitorować?
    Jaka forma archiwizacji?
    Jaki jest obecny sterownik i czy chcesz ingerować w jego oprogramowanie , czy może kolejny do samego monitoringu.?
    Pozdr Daro
  • IGE-XAOIGE-XAO
  • Level 23  
    Przerabiałem wszystkie 3 sposoby, efekt po kilku latach dla każdego sterownika (siemens) dodatkowy procesor komunikacyjny CP-343 lub CP443 advanced, podane serwery NTP, w sterownikach uniwersalny bloczek do przygotowywania danych, na to wszystko OPC i draivery do napychania baz danych. Oczywiście na to odpowiednia polityka IT, Vlany, w procesorach wyłączone wszystkie zbędne usługi www,ftp etc.
  • Level 10  
    Monitorowanie głównie stanu maszyn, ich aktualna prędkość itp. Potem wyliczane statystyki itp.
    Tak, żeby ktoś kto zarządza widział co się aktualnie dzieje.
    Wysyłane do chmury przy pomocy MQTT.
    Sterowniki są różne, Siemens, Omron, Saia - ale do większości nie ma programu źródłowego albo w ogóle program jest z hasłem.Są też sterowniki producentów maszyn, do których dostępu nie mam.

    zembol: Napisałeś, że wszystkie 3 sposoby próbowałeś i po jakimś czasie "procesor komunikacyjny CP-343 lub CP443 advanced", ale to oznacza, że dostawałeś się do sterownika urządzenia i modyfikowałeś program, czy był to dodatkowy sterownik a dane zbierałeś tymi sposobami, które podałem?
  • Helpful post
    Level 23  
    Maidey na wstępie krótka historia :). System który mam na myśli przeszedł długa drogę. Zaczynaliśmy kilka lat temu, wtedy całość zbierał sterownik plc, po całym zakładzie rozprowadzona była sieć profibus i z dużą ilością repeaterów (zasięg i struktura sieci). Dane ze sterowników były zbierane na różne sposoby tam gdzie w maszynie była sieć profibus instalowany był dp coupler, w sterowniku maszyny oczywiście zmiany w hw, sam program to tylko przepisywanie stanów czujników na dp coupler, tam gdzie maszyny nie miały sieci profibus instalowany był moduł wejść, do niego podpięte albo dodatkowe czujniki i/lub przyciski albo "kradzione" sygnały przez przekaźniki. Wybraliśmy takie rozwiązanie ponieważ mieliśmy obawy aby bardziej ingerować w plc maszyn. Oczywiście po drodze dużo zmian jedne maszyny złomowano inne wstawiono, a to powodowało duże komplikacje jeśli chodzi o rozbudowę i zmiany w naszym systemie. Problem polegał tez na tym ze jako utrzymanie ruchu nie chcieliśmy odpowiadać za ten system. Niestety takie rozwiaznie powodowało ze na maszynach było mnóstwo "sztucznych nerek" za które i tak byliśmy i tak odpowiedzialni. W końcu z kolegą zaproponowaliśmy nowe rozwianie oparte o OPC.
    Dla wyjaśnienia dodam ze mam to szczęście ze dostawcy maszyn musza udostępnić kody źródłowe, projekt w eplanie itp., zawarte to jest w umowach z producentami. Dodatkowo posiadamy wytyczne dla producentów maszyn zarówno jeśli chodzi o aspekty związane z automatyka, mechaniką, pneumatyka hydraulika siłowa. Np. mam zapis ze każdy cpu musi posiadać dodatkowy procesor komunikacyjny.
    Co do tematu software mamy dwa standardowe FB jedno obsługuje dane związne z wydajnością, taktami pracy te dane trafiają do systemów produkcyjnych, drugi bloczek obrabia dane tylko dla nas (utrzymanie ruchu) takie jak stan maszyny, temp, ciśnienia itp.. Teraz dodanie maszyny do systemu jest banalnie proste i odbywa sie zanim maszyna zostanie oddana do produkcji tzn. Producent dostaje wytyczne odnosnie konfiguracji procesora komunikacyjnego ip maska itp., dodatkowo implementuje nasze FB , a u nas w tym czasie ludzie odpowiedzialni ze opc, serwery aplikacyjne i bazodanowe tworza konfiguracje pod nowe urzadznie.
    Oczywiście zadaje sobie sprawę ze nie każdy ma takie możliwości jak ja. Ale naprawdę proszę mi wierzyć, teraz odbywa sie to tylko przez wpięcie rj do dedykowanego procesora, czysto prosto i bez obsługi (automatycy wiedze ze te dwa FB to "swięte FB" :), w porównaniu do tego co było kiedyś dodatkowe czujniki, zwarcia, problemy z siecią profibus, padające przekaźniki :), normalnie masakra.
  • Level 10  
    Dzięki za wylewną odpowiedź. Na pewno odpowiedział mi na moje pierwsze pytanie, tj, że moje sposoby są stosowane, a to, że to dodatkowe naczynia połączone. Jestem tego świadom, ale u mnie maszyn jest kilkadziesiąt i są to różni producenci. Do większości nie ma kodów źródłowych, co najwyżej opis działania. Najlepsze, że do niektórych nawet nie ma kopii programu, nawet takiej z hasłem.
    Fajnie jak masz możliwość i producenci dostarczają Wam otwarty sterownik. Świetna sprawa, nawet pod samym względem większej efektywności czy poprawie bezpieczeństwa, bo niekiedy potrafią "dać ciała' ;)

    A czy jest jakiś sposób, żeby, jeżeli wiemy jaki sygnał za co odpowiada i które chcemy pobrać, żeby te sygnały pobrać ze sterownika jakimś protokołem bez edycji programu? Np wiemy, że chcemy wysłać stany wyjść Q0.0, Q0.1, Q0.2, ale nie chcemy tego robić przekaźnikami tylko bezpośrednio ze sterownia?
    Zakładam, że bez edycji programu się nie obejdzie?
  • Level 36  
    Maidey wrote:
    Zakładam, że bez edycji programu się nie obejdzie?


    Jeśli jeden sterownik ma pobrać to drugi musi wysłać, więc edycja programu jeśli to wysyłanie nie jest teraz realizowane będzie konieczna.
  • Level 10  
    Ok, to mnie trochę upewniło w moich przemyśleniach.

    Jeśli nie mam dostępu do sterownika to w miarę łatwo skopiuje sobie sygnały cyfrowe 0-1.
    A co z sygnałami analogowymi. Wiadomo, w teorii podłączam się równolegle do sygnału napięciowego 0-10V, a szeregowo do prądowego np 4-20mA. Tylko czy mogę tak zrobić i czy to nie wpłynie na oryginalny pomiar, tym bardziej, jeżeli nie możemy wprowadzać dodatkowego błędu pomiarowego?
    Przekaźnik dla sygnałów cyfrowych zapewnia mi jednocześnie odizolowanie dwóch układów, a jak w przypadku analogowego?
    Jeśli "kopiowaliście" takie sygnały to czego do tego używaliście, zakładając, że chcemy odizolować sygnał "oryginalny"od tego idącego do dodatkowego sterownika zbierającego informacje?
  • Level 18  
    W przypadku sygnałów analogowych można używać duplikatory sygnałów