Witaj w kolejnej części cyklu o bibliotekach .Net do komunikacji ze sterownikami Siemens-a. Zajmiemy się dzisiaj pokrótce samym protokołem komunikacyjnym oraz niezbędną konfiguracją po stronie sterownika (w przypadkach gdy jest takowa potrzebna).
Do niedawna niekwestionowanym królem w świecie Siemens-a jeżeli chodzi o komunikację PC-PLC był standard Profibus/Mpi. Komunikacja ethernetowa była oczywiście dostępna, ale w przypadku niższych modeli sterowników wymagała dokupienia specjalistycznego procesora komunikacyjnego. W najnowszych seriach sterowników 1200 i 1500 ethernet jest już standardowo na pokładzie.
W tym cyklu będziemy się zajmować jedynie komunikacją ethernetową. Zestawienie komunikacji Profibus/Mpi wymagło by zakupu dodatkowej karty pośredniczącej lub konwertera Profibus/Mpi – Ethernet (np. takiego). Problem ten dotyczy głównie sterowników starszych i pewnych specyficznych układów, gdzie z różnych względów nie można zastosować ethernetu.
PROTOKÓŁ S7
Komunikacja w świecie sterowników Siemens bazuje na tzw. protokole S7. Protokół ten, w warstwie ethernetowej bazuje na standardzie ISO over TCP. Poszczególne bloki nazywane są tutaj PDU (Protocol Data Unit) a ich długość zależy od CPU lub procesora komunikacyjnego realizującego komunikację po stronie sterownika i jest negocjowana w trakcie nawiązywania połączenia (rozmiar mieści się w zakresie 240 – 960 bajtów). W przypadku gdy przesyłana ilość danych przekracza wynegocjowaną długość PDU, wiadomość jest odpowiednio dzielona.
Protokół S7 bazuje na komendach. Każda ramka zawiera albo komendę wysyłaną do sterownika albo odesłaną odpowiedź. Komendy mogą dotyczyć zapisu/odczytu danych z bloków, sterowania stanem sterownika, odczytu parametrów konfiguracyjnych czy też funkcji związanych z bezpieczeństwem. Wszystkie biblioteki, które będę tu opisywał implementują w postaci odpowiednich metod te komendy.
Protokół S7 nie jest niestety opisany w żadnej oficjalnej dokumentacji Siemens-a. Jeżeli chcielibyśmy się pokusić o własną implementację to pozostaje jedynie podsłuchiwanie np. za pomocą Wireshark komunikacji (nota bene posiada on specjalny plugin filtrujący jedynie komunikację S7) lub analiza kodu istniejących bibliotek.
Warto tutaj nadmienić, że ze względu na pewne zaszłości związane z architekturą sprzętową formaty danych w sterowniku różnią się od tych, z którymi mamy do czynienia w przypadku systemów komputerowych. W przypadku liczb mamy do czynienia z tzw. notacją Big Endian. W notacji tej najbardziej znaczący bajt zapisywany jest jako pierwszy. W przypadku rodziny x86 z którą mamy do czynienia w przypadku klasycznych komputerów stosowaną notacją jest Little Endian – najmniej znaczący bajt jest zapisywany jest jako pierwszy. W specyficzny sposób zapisywane są również formaty daty i czasu oraz stringi. Większość bibliotek komunikacyjnych ma odpowiednie funkcje związane z konwersją tych formatów.
PARAMETRYZACJA STEROWNIKA
W przypadku sterowników S7-300 i S7-400 a także starych S7-200 i LOGO mamy do czynienia z klasyczną implementacją protokołu S7. Żadna dodatkowa parametryzacja (oczywiście poza konfiguracją adresu IP, bramy itp. ) nie jest tu potrzebna, aby skorzystać z biblioteki komunikacyjnej.
W przypadku sterowników S7-1500 i od pewnego czasu S7-1200 mamy do czynienia z rozszerzoną wersją protokołu S7, związaną z kodowaniem komunikacji ze względu na zaimplementowane funkcje bezpieczeństwa. Kodowana komunikacja nie jest póki co obsługiwana przez żadną ze znanych mi bibliotek. Możemy jednak zmusić te sterowniki do pracy w trybie protokołu zgodnym z serią 300/400. Warto jednak mieć na uwadze, że rezygnacja z funkcji zabezpieczających może mieć pewne realne konsekwencje, warto więc zastanowić się jak można w inny sposób zabezpieczyć system sterownikowy przed niepowołanym dostępem.
Dodatkowo w przypadku sterowników 1200 i 1500 mamy do czynienia z nowym formatem bloków danych (tzw. optymalizowanym) gdzie adres odpowiedniej zmiennej jest dynamiczny a do samej zmiennej programując sterownik odwołujemy się po jej nazwie. Jeżeli chcemy czytać takie dane, blok w którym się one znajdują musi być oznaczony jako nie optymalizowany – musimy znać konkretny adres zmiennej aby się do niej odwołać.
Należy dodatkowo wyłączyć wszystkie funkcje bezpieczeństwa i zezwolić na realizację komunikacji PUT/GET.
Warto pamiętać również o tym, że w każdym z w/w przypadków nawiązując połączenie musimy poprawnie podać numer kasety (rack) oraz pozycję (slot) , w której znajduje się CPU. W zależności od rodziny sterowników wygląda to nieco inaczej:
W kolejnej części przejdziemy do opisu pierwszej z bibliotek.
Wszystkie posty w tym cyklu:
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – wstęp
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – protokół S7 i konfiguracja sterownika
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – projekty testowe
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – biblioteka s7netplus
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – biblioteka Sharp7 (Snap7)
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – biblioteka DotNetSiemensPlcToolboxLibrary