Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Jaki protokół komunikacyjny między różnymi PLC

Maidey 06 Feb 2018 10:38 1641 12
SterControl
  • #1
    Maidey
    Level 10  
    Witam,

    Chciałbym w mojej instalacji przesyłać informację ze sterownika maszyny (różni producenci i typy) do sterownika obsługującego wizualizację (Beckhoff CX....).

    Mam dowolność wyboru protokołu komunikacyjnego, który zainstaluje w obu sterownikach, i moje pytania to:

    1. Jaki protokół komunikacyjny polecacie do przesyłania informacji między sterownikami, za pośrednictwem sieci ethernet w firmie?

    2. Jaki protokół komunikacyjny polecacie do przesyłania informacji między sterownikami, za pośrednictwem wydzielonej sieci/bezpośredniego kabla komunikacyjnego?

    Nie jest to sterowanie, tylko wizualizacja dlatego nie ma znaczenie opóźnienie, które może wystąpić np w otwartej sieci ethernet, a nie trzeba w wielu przypadkach prowadzić dodatkowego okablowania.

    Z góry dzięki za opinie :)
    Pozdrawiam
  • SterControl
  • #2
    Rariusz
    Automation specialist
    Witam,
    Maidey wrote:

    1. Jaki protokół komunikacyjny polecacie do przesyłania informacji między sterownikami, za pośrednictwem sieci ethernet w firmie?
    2. Jaki protokół komunikacyjny polecacie do przesyłania informacji między sterownikami, za pośrednictwem wydzielonej sieci/bezpośredniego kabla komunikacyjnego?

    Maidey wrote:

    Nie jest to sterowanie, tylko wizualizacja


    Skoro wizualizacja to po co wymiana danych miedzy sterownikami ?

    Pozdrawiam,
  • #3
    kornik280
    Level 18  
    Najbardziej uniwersalny pewnie modbus tcp
  • SterControl
  • #4
    Maidey
    Level 10  
    Rariusz wrote:


    Skoro wizualizacja to po co wymiana danych miedzy sterownikami ?

    Pozdrawiam,


    Wymiana tzn sterownik z maszyny przesyła dane do tego od wizualizacji, tylko w jedną stronę.
    Dzięki temu nie mam dodatkowych kabli, przekaźników, czujników idp.
    Dodatkowo w ten sposób mogę wysyłać aktualne parametry, treści alarmów itp.
    Jeden sterownik zbiera dane z kilku maszyn.
  • #5
    Rariusz
    Automation specialist
    Witam,

    Pogubiłem się...Pytasz o protokół do wymiany danych a później piszesz że
    dane sa wymieniane...

    Można zbierać wszystko do wizualizacji z pominięciem sterownika ale jak już
    tak jest to podaj co za sterowniki są zainstalowane na maszynie i jak
    wizualizacja...sprecyzuj problem.

    Pozdrawiam,
  • #6
    Zgoodie
    Level 24  
    OPC UA wydaje sie dobrym rozwiązaniem obecnie.
  • #7
    pearlchili
    Level 14  
    Również stawiałbym na OPC.
    Poza tym wiele wizualizacji natywnie obsługuje ten protokół.
  • #8
    elektronikq
    Level 24  
    Jak siemens to może być profibus lub profinet. Fajnie to się zestraja w Tia.
  • #9
    Maidey
    Level 10  
    Witam

    Dzięki za odpowiedzi.

    W ramach uściślenia. Informacje zbierane przeze mnie, o aktualnym statusie maszyny, będą wysyłane bezpośrednio na chmurę.

    W oprogramowanie urządzeń nie ingeruje, mogę zlecić coś takiego producentowi urządzenia, natomiast producent jednego z urządzeń zadał mi pytanie jaki protokół chce to taki mi zamontują.

    Dlaczego nie pominąć sterownika i od razu nie wysyłać przez OPC?
    Bo sterownik będzie zbierał dane z kilka maszyn, różnych sterowników, możliwe, że różnymi protokołami, bo niektóre mogą być narzucone, jak i zbierać dane za pomocą czujników/przekaźników z niektórych urządzeń, jeśli nie ma możliwości ingerencji w sterownik lub koszty tego są zbyt duże.

    Dlatego pytanie było o protokół który jest polecany w ogólnym rozrachunku, bez dopasowywania pod konkretny model sterownika, bo będą różne.
    Beckhoff używa np głównie EtherCAT, Real-Time Ethernet, ale może w niektórych sterownikach to dużo zabawy i lepiej zainstalować np Profinet.

    Pozdrawiam
  • Helpful post
    #10
    dzik84
    Level 17  
    EtherCAT czy Profinet są głownie używane do samego sterowania - komunikacja sterownik-sterownik, sterownik-napęd, sterownik-rozproszone IO itd

    OPC UA zaś najlepiej sprawdza się do wizualizacji/SCADY/gromadzenia danych z własnie różnych urządzeń - dokładnie to co potrzebujesz.
    Dużo urządzeń/systemów go domyślnie wspiera
  • Helpful post
    #11
    zoltar_vero
    Level 12  
    Moim zdaniem, trochę zły kierunek. Pytanie podstawowe: jakie typy PLC są w firmie ? Trzeba pamiętać, że np. obsługa Modbus w S7-300 jest dodatkowo płatna. Nie lepiej zainstalować na jakimś PC lub serwerze np. OPC Kepware multidrive? Koszt takiego OPC około 2000$ z 2-3 letnim wsparciem. Ja mam zastosowane takie rozwiązanie, a na firmie mam PLC Siemens S7-200;S7-300;S71200;S71500, Omron Cx;NJ, Mitsubishi FX3 i Q, Festo FEC, Allen Bradley Compact; Micro. Wszystko działa świetnie, dane są wymieniane między PLC, a OPC Kepware z różnymi protokołami: EthernetIP, Modbus TCP, CIP, Profinet. Do maszyn, które nie mają eternetu na pokładzie podpiąłem serwery RS-Lan - dobrze sprawdzają się rozwiązania Moxa. Jedyna rzecz, na którą trzeba zwrócić uwagę, to ilość połączeń z PLC. Duża część PLC ma ograniczenia np. do 16-32 połączeń z innymi urządzeniami po eternecie i czasami ratuje się podpięciem dodatkowej karty sieciowej do PLC- o ile pozwala na to typ PLC. Dane wysyłam w chmurę, gdzie są obrabiane i wracają na halę produkcyjną w postaci wizualizacji poprzez rozwiązania Rise Vision. Obecnie tworzę lokalną SCADA, w trochę innym celu niż już działające rozwiązanie chmurowe i będzie oparte równolegle o OPC Kepware. W razie pytań, chętnie podpowiem.
  • #12
    Maidey
    Level 10  
    dzik84 wrote:
    EtherCAT czy Profinet są głownie używane do samego sterowania - komunikacja sterownik-sterownik, sterownik-napęd, sterownik-rozproszone IO itd
    OPC UA zaś najlepiej sprawdza się do wizualizacji/SCADY/gromadzenia danych z własnie różnych urządzeń - dokładnie to co potrzebujesz.
    Dużo urządzeń/systemów go domyślnie wspiera.


    zoltar_vero wrote:
    Moim zdaniem, trochę zły kierunek. Pytanie podstawowe: jakie typy PLC są w firmie ? Trzeba pamiętać, że np. obsługa Modbus w S7-300 jest dodatkowo płatna. Nie lepiej zainstalować na jakimś PC lub serwerze np. OPC Kepware multidrive? Koszt takiego OPC około 2000$ z 2-3 letnim wsparciem. Ja mam zastosowane takie rozwiązanie, a na firmie mam PLC Siemens S7-200;S7-300;S71200;S71500, Omron Cx;NJ, Mitsubishi FX3 i Q, Festo FEC, Allen Bradley Compact; Micro. Wszystko działa świetnie, dane są wymieniane między PLC, a OPC Kepware z różnymi protokołami: EthernetIP, Modbus TCP, CIP, Profinet. Do maszyn, które nie mają eternetu na pokładzie podpiąłem serwery RS-Lan - dobrze sprawdzają się rozwiązania Moxa. Jedyna rzecz, na którą trzeba zwrócić uwagę, to ilość połączeń z PLC. Duża część PLC ma ograniczenia np. do 16-32 połączeń z innymi urządzeniami po eternecie i czasami ratuje się podpięciem dodatkowej karty sieciowej do PLC- o ile pozwala na to typ PLC. Dane wysyłam w chmurę, gdzie są obrabiane i wracają na halę produkcyjną w postaci wizualizacji poprzez rozwiązania Rise Vision. Obecnie tworzę lokalną SCADA, w trochę innym celu niż już działające rozwiązanie chmurowe i będzie oparte równolegle o OPC Kepware. W razie pytań, chętnie podpowiem.


    Dzięki za opinie.

    Sprawa wygląda tak, że nie wiem jakie sterowniki zastanę, bo to zależy od firmy w której będę. Pisząc pierwszy post miałem taką opcję jak opisałem, ale na razie temat stoi. Na chwilę obecną trafiają mi się urządzenia do których właściciele nie mają dostępu (program PLC), a ja jako osoba, którą ma tylko zrealizować monitoring i wizualizację unikam tego ze względu na dużą odpowiedzialność - tak na prawdę wystarczy, że się podepnę i nic nie zrobię, a przy pierwszej awarii wiadomo kogo ścigać.

    Na chwilę obecną zbieram proste sygnały optoprzekaźnikami i czujnikami.
    Natomiast może się zdarzyć, że użytkownik będzie chciał, żeby nie montować żadnych urządzeń tylko zbierać dane bezpośrednio ze sterownika i, że skontaktuje się z producentem, żeby jakieś dane wystawiał. Chciałem ustalić co w takiej sytuacji będzie najlepszą, uniwersalną opcją, albo uniwersalną jeśli chodzi o jakieś sterowniki.

    Dlaczego nie korzystałem z OPC UA. Do tej pory nie miałem sygnałów ze sterownika , tylko "wykradałem" je z maszyny, w sterowniku obrabiałem dane wyjściowe i wysyłałem na chmurę ich przeliczenia za pomocą protokołu MQTT. Tam wykonywałem wizualizację itd.

    Nie używałem do tej pory OPC UA. Wdrażam się w rozwiązania sieciowe - do tej pory wszystko lokalnie było. Rozumiem, że dało by się za jego pomocą zbierać informacji z wielu maszyn bezpośrednio, bez obrabiania na serwer, tam obrabiać i przesyłać to co potrzeba na chmurę?


    Pytanie drugie jeszcze mi się nawineło:
    Jak wygląda podłączanie się do maszyny w celu monitoringu np taki przkekaźnikiem i czujnikiem, a przepisy i dyrektywę maszynową?
    Moim zdaniem przy wykonywaniu monitoringu zachodzi Modernizacja (nie Modyfikacja), poprawiająca bezpieczeństwo maszyny (monitorujemy występowanie awarii itd - na podstawie zapisu analizowania danych możemy awarii zapobiegać w przyszłości, cy po prostu szybciej reagujemy na awarię poprzez szybsze zgłoszenie awarii, widzimy kiedy maszyny zachowuje się inaczej (inny materiał, warunki środowiskowe)).

    Pozdrawiam
  • Helpful post
    #13
    zoltar_vero
    Level 12  
    Hehe. Jeśli chodzi o podpinanie się, lub pojawienie nawet w pobliżu linii, mam podobny problem. Jeśli chodzi o OPC UA, to standard dopiero się rozwija u wielu producentów PLC. Omron dopiero certyfikował nowe sterowniki seri NJ, Siemens dopiero je wdraża tak naprawdę - niestety u wielu producentów jest to osobny model sterownika - ze standardem OPC UA. Nie oczekuj, że sterownik 4-5 letni wspiera ten standard. Jeśli chodzi o rozwiązania sieciowe typu OPC server, to w części PLC nie wymaga żadnej ingerencji w oprogramowanie sterownika - np. Omron CJ2,Siemens S7-300,S7-1200, S71500, Allen Bradley Compact wszystkie tagi, zmienne są widziane przez OPC server. Wystarczy jedynie sprawdzić ile połączeń sieciowych obsługuje PLC i ile już ma wykorzystanych, żeby nie odciąć np. panela HMI od PLC. Część np. Mitsubishi FX3;Fx5; seria Q wymaga dodania w konfiguracji adresu serwera OPC wraz z protokołem i portem. W Omron NJ w tabeli zmiennych należy odpowiednie zmienne zmienić na "opublikowane"-dostępne z poziomu sieci i serwera OPC. Inne sterowniki, a jest ich naprawdę wiele mają podobne rozwiązania. Jeśli chodzi o tematykę sieciową, to w przyszłym tygodniu są targi Automaticon, będą kopalnią wiedzy i rozwiązań - można wybrać parę rozwiązań - po targach można zaprosić firmy na pokaz praktyczny u siebie. Jeśli chodzi o drugie pytanie, to na szczęście nie mam problemu z modyfikacjami maszyn i linii, każda jest wykonana pod unikalny produkt - jest także w pewien sposób eksperymentalna i producent razem z nami dokonuje zmian hardware-software. Czasem wystarczy, że w emailu wysyłam zakres zmian, schemat - na tej podstawie producent przyklepuje zmiany i potwierdza ciągłość CE. Nie wszędzie jest jednak tak kolorowo - niektórzy producenci nie chcą nawet obcych tabliczek identyfikacyjnych, np. zgodnych z polityką firmy na maszynie, nie mówiąc już o ciałach obcych w szafach sterowniczych - przekaźniki, czujniki, itp. Wszystko zależy od producenta.
    Jeśli masz wątpliwości co do zmian dokonywanych na maszynach i certyfikatu CE, to odsyłam do strony https://bezpieczenstwowsystemachsterowania.pl .
    Dodano po 2 [godziny] 9 [minuty]:
    Dodałem kilka zrzutów ekranu, żebyś mógł zobaczyć możliwości serwera OPC multidrive. Jak widać do jednego PC spływają różnego typu dane z różnych PLC, nawet z Siemens Logo 8. Dane są typu Bool, Word, Array, Bool Array, DWord, String, itp. W ten sposób mam w firmie zapiętych po sieci eternet 70 PLC, 45 PC i IPC i około 150 paneli HMI do jednego serwera OPC zainstalowanego w serwerowni UR na serwerze Fujitsu. Gdyby miał to być zwykły PC, to też dałby sobie radę, ja jednak wykorzystuję go także do innych zadań, min. backup z PLC i PC po sieci, oraz nadzór nad siecią.

    Jaki protokół komunikacyjny między różnymi PLCJaki protokół komunikacyjny między różnymi PLCJaki protokół komunikacyjny między różnymi PLC