Modbus RTU - Jak połączyć PLC, panel, falownik

Witam

Mam następujący problem.
Posiadam sterownik GE Fanuc VersaMax Micro z dwoma portami komunikacyjnymi.
Pierwszy jest to RS232, drugi (który chcę wykorzystać do komunikacji), to RS485.

Chciałbym podłączyć do drugiego portu (RS485) falownik oraz touchpanel Weintek.
Jak należałoby skonfigurować urządzenia do pracy z Modbus RTU?
Czy PLC ma być master'em, a pozostałe urządzenia slave'ami?
Jak w tym przypadku będzie się zachowywał panel?
Czy PLC będzie musiał posiadać logikę do cyklicznej wymiany danych?

Założeniem jest sterowanie urządzeniem z panela TP (kontrola, parametryzacja, status).
Następnie PLC ma sterować falownikiem.

Będę wdzięczny za pomoc.
Pozdrawiam

Witam
Ta konfiguracja, którą opiałeś jest oczywiście możliwa. Serownik PLC + panel + falownik (przetwornica) podłączone mogą być jeśli tylko spełnią kilka warunków
1. Wszystkie mogą pracować na RS 485 po protokole Modbus
2. Panel jest ustawiony jako master
3 PLC jako slave wykonawca roskazów z panela i jednocześnie wykonujący własny algortm sterowania.
4 Falownik jako slave wykonawca rozkazów z panela
5.Każde z urządzeń podłączonych do linii Modbus musi mieć swój unikalny adres konfigurowalny w urządzeniu (PLC, Panel, falownik)
W. Panelu musisz miec zaimlementowany protokół który ustawi odpowiednie rejestry w PLC oraz uumozliwi komunikację z falownikiem. Sterować możesz falownikiem na dwa sposoby, pierwszy to poprzez algoryytm PLC sterując odpowiednimi wejściami falownika (start, stop, forward, reverse..) a drugi to wystawiając z Panel (master) poprzez Modbus (rs485) odpowiednie komendy w rejestrach
pozdrawiam

Witam i dziękuję za odpowiedź.

Niestety żadne z rozwiązań nie satysfakcjonuje mnie
Falownikiem musi sterować PLC, a chciałem uniknąć sterowania zaciskami.
Poza tym zależy mi na zadawaniu prędkości oraz odczycie parametrów oraz statusów.

Np. w Profibusie nie ma problemu. Wszystko podłączam pod jedną magistralę i śmiga.
Mam możliwość sterowania falownikiem z PLC, a panel operatorski odczytuje/zapisuje stany PLC.

Modbus niestety jest inny i wymagany jest układ Master-Slave.
Chyba skończy się na tym, że urządzenia będą w następującej konfiguracji:
- PLC - Master
- TP - Slave
- FI - Slave
Wtedy nadrzędną jednostką kontrolującą będzie PLC, jednak w celu komunikacji z panelem, trzeba będzie "ręcznie" robić z nim wymianę danych (chyba, że panel będzie miał inną opcję).

Innym rozwiązaniem jest wykorzystanie dwóch portów komunikacyjnych.
VersaMax Micro posiada na pokładzie:
- Port 1 - RS232 (także służy do programowania)
- Port 2 - RS485 (opcjonalna karta)
Wtedy mógłbym połączyć się z panelem po RS232, a z falownikiem po RS484, wykorzystując w obu przypadkach Modbus RTU.
Obawiam się wpływu zakłóceń na RS232 (komunikacja z panelem). Co prawda odcinek nie będzie zbyt długi (około 50-80cm), ale w tej samej szafce jest falownik.
Kolejna sprawa to zajmowany port programatora i utrudniony przez to dostęp do sterownika.

Czekam na dalsze sugestie/propozycje.

Pozdrawiam

Ja użyłbym obu portów: RS 485 do komunikacji z falownikiem, PLC jako master, natomiast RS 232 do komunikacji z panelem, panel jako master. Oba kable ekranowane i zakłócenia nie powinny być problemem.

Z tego co pamiętam nie wszystkie modele VersaMicro wspierają pracę jako Modbus Master. Najmniejszy 14 punktowy miał tylko tryb Slave. Nie podajesz modelu PLC, ale piszesz o dwóch portach komunikacyjnych, więc pewnie > 28 punktów i tam jest OK, ale obydwa porty nie będą działać jednocześnie jako Master.

Witam

Uzupełniam dane. PLC który posiadam jest największym modelem 64-punktowym.
Pierwszy port - standardowy programatora - RS232 (SNP, RTU, Serial I/O).
Drugi port - opcjonalna karta - RS485 (SNP, RTU, Serial I/O).
Jak tylko dostanę panel Weintek MT6070iH, wezmę się do testów.

Pozdrawiam

Cytat:

Np. w Profibusie nie ma problemu. Wszystko podłączam pod jedną magistralę i śmiga.
Mam możliwość sterowania falownikiem z PLC, a panel operatorski odczytuje/zapisuje stany PLC.

Modbus niestety jest inny i wymagany jest układ Master-Slave.

No przecież Profibus to też układ master-slave (no chyba ze urządzenia obsługują specyfikacje DPV2).

Możesz spokojnie zastosować rozwiazanie PLC Master Falownik I OP Slave. Sprawa rozbija się jedynie o dopuszczalne opóźnienia. Master Inicjuje komunikacje ze slave'm i a potem czeka na odpowiedź, Dalej następny slave itd. Przyjmuje się że dla jednego slave Master potrzebuje max 1s na pytanie i odpowiedź. W takiej konfiguracji musisz się wiec spodziewać opóźnień rzędu 2 s.

Zgadzam się z przedmówcą.
Jednak ciągle chodzi mi o konfigurację Master-Slave.

Czy jest możliwe, aby PLC był Master'em, a FI i TP Slave'ami?
Czy w tym przypadku będę musiał stosować jakieś specjalne zabiegi w TP, aby odczytywać dane z PLC?
Rozumiem, że w tym przypadku Slave nie będzie mógł zainicjować transmisji.
Proszę mnie poprawić w przeciwnym przypadku.

Pozdrawiam

jam_es napisał:

Czy jest możliwe, aby PLC był Master'em, a FI i TP Slave'ami? Czy w tym przypadku będę musiał stosować jakieś specjalne zabiegi w TP, aby odczytywać dane z PLC?

Falownik może być Slave, PLC może być Master.
Nie wiem czy Twój panel może być Slave, nie podałeś jego typu. Po prostu zajrzyj do dokumentacji.

jam_es napisał:

Rozumiem, że w tym przypadku Slave nie będzie mógł zainicjować transmisji.

Stacja Slave z definicji nie może inicjować transmisji. Musi być odpytywana przez stację Master, np. cyklicznie.

arwit napisał:

Przyjmuje się że dla jednego slave Master potrzebuje max 1s na pytanie i odpowiedź.

To się liczy. Wymiana może zmieścić się w 100 ms, a czasem 3 s to mało.

Podtrzymuję swoje zdanie

Cytat:

RS 485 do komunikacji z falownikiem, PLC jako master, natomiast RS 232 do komunikacji z panelem, panel jako master.

Cytat:

To się liczy. Wymiana może zmieścić się w 100 ms, a czasem 3 s to mało.

I tak i nie. Takie dane powinny sie znajdować w DTR urządzenia a liczenie to jedynie sumowanie czasów odpowiedzi lub np: mnożenie czasów odpowiedzi przez ilość odpytywanych zmiennych. 1s to tylko przykład.

Cytat:

Czy w tym przypadku będę musiał stosować jakieś specjalne zabiegi w TP, aby odczytywać dane z PLC?

Nie. Generalnie Master cyklicznie odpytuje slave o wartosci z rejestrów oraz może również do niektórych zapisywać. To jest tylko kwestia co inicjuje transmisje ( w tym przypadku PLC)

Zastosowanym panelem (jak wspominałem wcześniej) będzie Weintek MT6070iH.
W sofcie do jego obsługi (EasyBuilder8000) jest możliwość wybrania następujących protokołów:
- Modbus ASCII,
- Modbus RTU,
- Modbus RTU (zero-based addressing),
- Modbus Server (Modbus RTU Slave) <- to tryb, który by mnie interesował.

W związku z tym najprawdopodobniej przeszedłby pierwotny pomysł komunikacji na jednej magistrali.
Czy muszę stosować terminację RS485, gdy całkowita jej długość będzie wynosiła ok 1,5-2m?
Struktura połączeń będzie następująca: FI <-> PLC <-> TP.

Cieżko jest mówić o czymś, czego nie ma się przed sobą.
Mam nadzieję, że wkrótce będę miał możliwość testów na "żywym organiźmie".

Pozdrawiam

Ok, jeśli MT6070iH to wybierasz opcję MODBUS SERWER w ustawieniach portu RS485 i ustawiasz panel jako SLAVE.

Nie muszę chyba wspominać, że falownik TEŻ musi być slave.

PLC jako jednostka najwyższa powinna być masterem i przez PLC sprawdzasz co się dzieje na panelu (odczytujesz jakiś zakres LB z panela na którym masz ustawione statusy przycisków wirtualnych co 100ms) i potem ustawiasz dane falownika pojedyńczym wysłaniem ramki RTU w przypadku jakichś zmian, np. prędkości, statusu...

W ten sposób wszystko będzie działało NAJSZYBCIEJ.

Problemy:
panowie z Wainteka nie udzielą za dużo pomocy bo dla nich najlepiej by było jakby panel był Masterem ale z własnych doświadczeń wiem, że działa równie dobrze jako Slave. Tajemnicą jest właśnie MODBUS SERWER którego u używam TYLKO I WYŁĄCZNIE, bo dla mnie panel jest raczej urządzeniem głupim i nie będzie mi decydował o komunikacji w całej sieci!

Dodano po 2 [minuty]:

Ok, jeśli MT6070iH to wybierasz opcję MODBUS SERWER w ustawieniach portu RS485 i ustawiasz panel jako SLAVE.

Nie muszę chyba wspominać, że falownik TEŻ musi być slave.

PLC jako jednostka najwyższa powinna być masterem i przez PLC sprawdzasz co się dzieje na panelu (odczytujesz jakiś zakres LB z panela na którym masz ustawione statusy przycisków wirtualnych) i potem ustawiasz dane falownika pojedyńczym wysłaniem ramki RTU.

W ten sposób wszystko będzie działało najszybciej.

Problemy:
panowie z Wainteka nie udzielą za dużo pomocy bo dla nich najlepiej by było jakby panel był Masterem ale z własnych doświadczeń wiem, że działa równie dobrze jako Slave. Tajemnicą jest właśnie MODBUS SERWER

Witam, jednak dalej chcesz konfiguracji PLC(master) FAL(slave) OP(slave) sądze, ze jest to złe rozwiązanie. Panel jest jednak urządzeniem (HMI) komunikującym się z człowiekiem w sposób dwukierunkowy jeśli ustalisz jego rolę na slave to niestety tylko w jedną stronę. Slav'y nie wydają poleceń urządzeniom, to chyba jest wiadome i logiczne.
Rozważ jednak moją propozycję to OP( master) PLC(slave) i FAL( slave) sprawnie może monitorować zmienne w Falowniku i PLC według harmonogramu OP(mastera). W sterowniku zawrzyj całą strukturę logiczną pracy Falownika, OP przekaże do określonych przez ID slav'ów informacje, alarmy, nastawy i polecenia . Nic nie stoi na przeszkodzie aby to PLC decydował na podstawie zmiennych otrzymywanych z OP prędkości, ogólnie rzecz ujmując stanie FAL...... OP jako jedyny ma możliwość komunikowania się nie tylko z FAL, PLC ale, co jest niezaprzeczalnym jego atutem Z CZŁOWIEKIEM. No chyba, że chcesz zrobić z OP wyświetlacz. Skłaniam się do zdania Panów ze serwisu OP MASTEREM ! w innym przypadku będzie to niesprawne urządzenie
Zamiast określenia wirtualny przycisk użyłbym zmienna typu MB (merker bit) charakterystyczna dla obiektów logiki dwustanowej (0,1).
Pozdrawiam
P.S.
Terminator stosujemy przy dłuuuugich liniach modbusowych w celu poprawy poziomu sygnału na linii cyfrowej, jaką jest linia modbus. Nalezy pamiętać, że nie powinna być ona typu gwiazda gdyż terminator powinien być włączony w najbardziej oddalonym urządzeniu slave.

elkam napisał:

Panel jest jednak urządzeniem (HMI) komunikującym się z człowiekiem w spodsób dwukierunkowy jeśli ustalisz jego rolę na slave to niestety tylko w jedną stronę. Slav'y nie wydają poleceń urządzeniom, to chyba jest wiadome i logiczne.

Mylisz niskopoziomowy protokół transmisji danych w sieci z przepływem danych w aplikacji. Nie ma żadnego problemu z wydawanem poleceń przez stacji Slave do Master, wystarczy gdy Master cyklicznie odpytuje Slave i wykonuje rozkazy jakie otrzyma po odpytaniu.

A czy to jest rozwiązanie najprostsze, najlepsze, czy przeciwnie - zależy od aplikacji.

Czy możesz podać źródło z którego wstawiłeś stronę z wykresem prędkość transmisji / długość linii?

Nic takiego nie napisałem, cały czas piszę o protokole komunikacyjnym między urządzeniami linii MODBUS a nie aplkacjami. Proszę czytać dokładnie posty.
Proszę uzupełnić swoje wiadomości na temat komunikacji typu Master-> Slave i nie wypisywać bzdur o "wydawaniu poleceń przez slava"... komu masterowi czy też innemu sleav'owi. Co najwyżej można je posluchć a to co innego.
Piszesz o "jakimś niskopoziomowym czymś".... o którą warstwę sieciową Ci chodzi bo to co piszesz nie jest zrozumiałe
Pozdrawiam
źródło :
Katedra Metrologii i Systemów Elektronicznych
Wydział Elektroniki, Telekomunikacji i Informatyki
Politechnika Gdańska

Kolego, trochę więcej dystansu.

Wytłumaczę na przykładzie. Aplikacja sterowania napędem.

Sterownik PLC z wyjściami sterującymi styczniki. Panel operatorski z ekranem i przyciskami start, stop i zmiana kierunku obrotów.

Przepływ danych w tej aplikacji jest następujący:
od panelu do sterownika PLC - polecenia operatora
od PLC do panelu - stan napędu

Przykład 1. Panel jest stacją Master. Wymiany cykliczne.
Wymiana 1. Rozkaz zapisu do PLC. Przesyłane dane są "rozkazem" w rozumieniu aplikacji.
Wymiana 2. Rozkaz odczytu z PLC. Przesyłane dane są "statusem napędu" w rozumieniu aplikacji.


Powyższe jest jasne?

Więc odwracamy sytuację.

Przykład 2. Panel jest stacją Slave, PLC stacją Master. Wymiany cykliczne.
Wymiana 1. Rozkaz odczytu z panelu. Przesyłane dane są "rozkazem" w rozumieniu aplikacji.
Wymiana 2. Rozkaz zapisu do panelu. Przesyłane dane są "statusem napędu" w rozumieniu aplikacji.

Rozjaśniłem? Takie konfiguracje sieci się czasem stosuje, choć rzadko.

elkam napisał:

Piszesz o "jakimś niskopoziomowym czymś".... o którą warstwę sieciową Ci chodzi bo to co piszesz nie jest zrozumiałe

Powtórzę. Mylisz niskopoziomowy protokół transmisji danych w sieci z przepływem danych w aplikacji. Modbus Serial jest zdeterminowanym czasowo protokołem dostępu do łącza - warstwa 2 modelu ISO/OSI.

Przepływ rozkazów i danych między węzłami sieci w danej aplikacji jest od niego zupełnie niezależny.

Aha. Przez "aplikacja" rozumiem

Cytat:

4. «zastosowanie czegoś w praktyce»

Ta strona jest z jakiegoś skryptu? Możesz podać autorów?

Witajcie Panowie

Widzę, że zainteresowanie wzrosło, ale również zrobiło się trochę nerwowo

Co do rozwiązania w swojej aplikacji, to bardziej odpowiada mi rozwiązanie proponowane przez Kolegę jestam.
W tym przypadku PLC jest nadrzędnym master'em, a falownik oraz panel slave'ami.
Oczywiście jestem świadom, że będę musiał cyklicznie wymieniać dane pomiędzy PLC<>OP.

Główną zaletą tego rozwiązania jest to, że PLC może bezpośrednio sterować falownikiem.
Realizuje on własny algorytm sterowania i w razie potrzeby kontroluje falownik.
Nie ma tutaj żadnych urządzeń pośredniczących w transmisji, a tym bardziej wprowadzających dodatkowe opóźnienia.
Oszczędzamy cenne ms w przypadku np. zatrzymywania falownika po najechaniu napędu na czujnik lub wciśnięciu E-STOP.
Dodatkowy plus, że teoretycznie układ może działać bez udziału panela (np. w przypadku awarii).
Nie trzeba także pisać skryptów na panelu, które realizowałyby sterowanie falownikiem.
Z założenia, w uproszczeniu, to PLC ma być "mózgiem" całego systemu, TP interfejsem, a FI elementem wykonawczym.

Teraz przyjdzie czas na realizację tej filozofii - myślę, że za około 2-3 tygodnie będę miał efekty.

Jakie przewody stosujecie jako medium transmisyjne dla ModBus na RS485? Czy jest to zwykła skrętka FTP/STP, czy może specjalistyczne (w stylu Profibus)?

Pozdrawiam

Hm.. without comment, hands drop ... cóż mozna jednak zaglądnąc do specyfikacji protokołu MB, jak jest taka potrzeba.
Powodzenia
P.S. Podtrzymuję swoje zdanie na temat rozwiązania, kolega zrobi tak jak zechce. A najlepiej jak zleci firmie integratorskiej rozwiązania problemu. Będzie fachowo.


Po informację na temat wpływu długości linii a szybkości transmisji zaglądnij do karty katalogowej SN75ALS194, nie wiem kto zredagował tę kartę jest ogólnie dostępna, rysunek z własnych zasobów, numer mojego kołnierzyka 43.... czy jeszcze kolega sobie coś życzy .
Miłego dnia

Tak się składa, że to ja mam być integratorem. Projekt, wykonanie i uruchomienie systemu.
Posiłkuję się doświadczeniem innych ponieważ sam nie korzystałem z Modbusa.
Prosta i jasna sprawa - w końcu ku temu jest stworzone to forum

@elkam:
O dokładne źródło pytałem, bo rysunek być może kiedyś mi się przyda. Ale wtedy nie będę mógł uzasadnić jego wiarygodności stwierdzeniem "znalazłem go na elektrodzie". A powołaniem karty katalogowej konkretnego układu owszem.

Co do opadających rąk...

W specyfikacji Modbus używa się pojęć request/response. Request jest tłumaczone na polski jako "rozkaz", "response" jako odpowiedź. Ale request znaczy "1. The act of asking." więc "rozkaz" nie jest najlepszym tłumaczeniem. Lepszym jest "zapytanie". W części literatury polskojęzycznej jest ono zresztą stosowane.

Więc: stacja Master wysyła zapytania do stacji Slave. Slave wysyła odpowiedzi na zapytania.

Cytat:

Slav'y nie wydają poleceń urządzeniom, to chyba jest wiadome i logiczne.

Slave ie wysyła zapytań do innych urządzeń. Slave może wydawać polecenia innym urządzeniom - za pośrednictwem stacji Master, która ogranizuje komunikację w sieci.

Jeszcze coś niejasne? Wytłumaczę

@jam_es:
W moim pierwszym poście w tym wątku sugerowałem, żebyś użył dwóch portów komunikacyjnych i zbudował dwie niezależne sieci: PLC-Falownik i Panel-PLC.
Jeżeli pozostaniesz przy jednej sieci, musisz spodziewać się znacznego wydłużenia cyklu komunikacji z falownikem gdyby panel został wyłączony/odłączony/uległ awarii, gdyż PLC jako master będzie musiał czekać na timeout gdy panel nie odpowiada.

Dobra, włączę się do tych teorii...

Elkam, jeśli piszesz tak wiele programów, że sugerujesz jakieś dziwne teorie na tem. "poleceń" z HMI do PLC to musisz też wiedzieć, że człowiek nie jest MASTEREM dla całych linii produkcyjnych, prawda?

To jest tak, człowiek wydaje polecenia z rozdzielczością 1/sek. PLC wydaje polecenia z rozdzielczością 1000/sek. Czy widać jakąś różnicę wg Ciebie?

A teraz inne pytanie: przypuśćmy, że masz 3 panele operatorskie. Czy wszystkie wg Ciebie będą masterami, bo przecież wszystkie podlegają jakiejś teorii komunikacji z człowiekiem przez HMI???


Pozdrawiam teorie

Ja jestem tylko nędznym praktykiem, tworzącym linie produkcyjne w oparciu o życie a nie wzniosłe teorie.....

_________________

Modbus RTU pracuje na moich fabrykach do 300m na zwykłym FTP (czasem przy przewodach ekranowanych z falownika).
Przy większych odległościach nie próbuj stosować połączenia w gwiazdę bo nie poradzi sobie. Ot cała tajemnica:-) Lepiej zachować konkretną kolejność slave'ów nawet przy większej długości niż łączyć w gwiazdę.

kk.2000 .......A teraz inne pytanie: przypuśćmy, że masz 3 panele operatorskie. Czy wszystkie wg Ciebie będą masterami, bo przecież wszystkie podlegają jakiejś teorii komunikacji z człowiekiem przez HMI??? ..........
Nie człowiek jest masterem tylko OP, który komunikuje się z człowiekiem a system
tylko jeden zgodnie z zasadą jeden Maser i wielu slave i tyle,
powtarzam należy rozgraniczyć wymianę danych z urządzeniami podległymi Masterowi od wykonywania programu siedzącego np. w PLC. Oknem na świat zewnętrzny dla PLC jest właśnie OP i to determinuje OP do bycia Masterem. Jest w tym bardzo dużo abstrakcji, niestety należy przyjąć konwencje zgodną dla danej grupy urządzeń tak aby jasno określić ich porządek w grupie. Jeśli wybierzesz w układzie, PLC jako master to w sytuacji gdy zarząda danych z OP a ich nie otrzyma lub otrzyma nieprawidłowe to jakby nie patrzeć będzie to, jesli nie obsłużymy takich sytuacji, błąd odpowiedzi slav'a. A co w sytuacji gdy operator chce zmienić zmienną X[x] odnoszącą się do prędkości falownika? Jeśli Masterem jest PLC to niestety musi bardzo często sprawdzać czy przypadkiem w zmiennej wyjścowej Slave'a [x] nie nastąpiła zmiana wartości, a co w sytuacji gdy nie ma zmiany? Taka interakcja jest zawodna i powodujaca możliwość wejścia PLC w jakąś nieobsłużoną pętlę
Rolą sterownika jest wykonywanie programu na podstawie zmienych cyfrowych i analogowych i wykonywanie algorytmu opisanego dla tych zmiennych
Rolą falownika jest wykonywanie kilku prostych zadań związanych ze startem i zatrzymaniem lub zmianą parametru wyjściowego (f)
Rolą OP przsyłaniem zmiennych między podległymi urządzeniam i ewentualne komunikowanie się z człowiekiem.
W panelach operatorskich niejednokrotnie osadzone są algorytmy ściśle współpracujące z urządzeniami slave
P.S
jest także protokół bardzo podobny do MODBUSA a został stworzony do sytuacji w których nalezy pogodzić dwa mastery, jest nim Modbus multimaster. Ale to już inna bajka
Pozdrawiam, wszystkich miłego dnia

Elkam, to wszystko co napisałeś powyżej o "jesli nie obsłużymy takich sytuacji", "PLC to niestety musi bardzo często sprawdzać ", o rolach sterownika, falownika i panelu i tak dalej, to wszystko prawda.

Żeby zrobić PLC masterem trzeba dobrze go oprogramować, czyli co tu ukrywać trzeba więcej pracy niż w sytuacji odwrotnej. Ale technicznie DA SIĘ. Podkreślę: protokołem Modbus da się przesyłać rozkazy na poziomie aplikacji od Slave do Master. A że to ma sens tylko w wyjątkowych przypadkach, to też pisałem wyżej. Autorowi wątku też takiego rozwiązania nie sugerowałem.

pozdrawiam

DOBRA, ostateczna odpowiedź bo za dużo jest tu teorii.

PLC M U S I być masterem w tej sytuacji którą opisuje elkam.

Dlaczego?

1. Jeśli nawali komunikacja w sieci to nie ważne czy Panel nie dotrze z informacją do PLC czy PLC nie dotrze z infiormacją do Panela ale wynik jest jednoznaczny: falownik będzie pracował wiecznie w taki sposób jak pracuje! Nie da się go wyłączyć ani zmienić danych. Sytuacja krytyczna!!!

2. Jeśli PLC jest masterem i nawali konunikacja z którymkolwiek ze Slave'ów to inne mogą pracować poprawnie i TO WŁAŚNIE determinuje PLC jako Mastera.

3. PLC posiada wiele innych łączy sterujących i to w NIM jest program rozkazujący. PLC wyłączy falownik jeśli stwierdzi, że zaginęła komunikacja z Panelem, SCADą albo innym ważnym Slave'm. Może to zrobić przez Modbus albo przez wyjście cyfrowe (zgodnie z dobrą praktyką automatyka).

Niestety, panel tego nie zrobi i jeśli nawali kiedykolwiek komunikacja między Panelem Master a PLC to sytuacja jest NIE DO OPANOWANIA przez użytkownika a PLC choć mądrze oprogramowane to pozostaje BEZUŻYTECZNE!.
____________________

Urządzeniem nadrzędnym MUSI być więc ostateczny DECYDENT o wszystkich operacjach na linii prod. i tu TEORIE podane przez elkama pozostaną tylko TEORIAMI.

Ostatecznym decydentem NIE JEST TU CZŁOWIEK, bo człowiek nie komunikuje się z falownikiem (człowiek ma wyłączniki bezpieczeństwa i moduł bezpieczeństwa). Panel też nie komunikuje się z falownikiem, ani ŻADNYM innym urządzeniem wykonawczym od którego zależy często życie ludzkie!!!

____________________________

Elkam, z całym szacunkiem dla wiedzy i pomysłowości, ale albo teoretyzujesz na temat automatyki choć nigdy nie projektowałeś linii prod. albo jesteś programistą niebezpiecznym dla otoczenia!

Pozwolę podpiąć się do tematu i zapytać kolegów o sprawę połączenia panelu Weintek z plc Fatek. Chodzi mi właśnie o protokół Modbus. Chcę ustawić Fateka jako Mastera. Czy istotne jest który numer w sieci zostanie przyporządkowany Masterowi, a który hmi? Nie wiem też który rejestr trzeba zapisać przy pomocy Modbus Master Table w WinProLadder, żeby zmienić np. rejestr LW0 panelu?

W sieci Modbus adresuje się tylko abonentów Slave. Abonent Master jest jeden, więc nie potrzebuje adresu. Nie jest istotne jaki adres przypiszesz do Slave, choć tradycja mówi że przypisuje się kolejno adresy od 1.

Przy połączeniu dwóch urządzeń prościej byłoby ustawić panel jako Master a sterownik jako Slave. Tak się zwykle robi.

jestam napisał:

Przy połączeniu dwóch urządzeń prościej byłoby ustawić panel jako Master a sterownik jako Slave. Tak się zwykle robi.

Niestety to będzie tylko przygotowanie do połączenia ze sobą większej ilości urządzeń więc plc musi być masterem.

jam_es napisał:

Oszczędzamy cenne ms w przypadku np. zatrzymywania falownika po najechaniu napędu na czujnik lub wciśnięciu E-STOP.

Zatrzymania awaryjnego nie możesz realizować za pośrednictwem PLC, szczególnie jeśli w grę wchodzi możliwość obrażeń u ludzi. Bo co będzie jak sterownik się zawiesi?

Ja komunikację w tym przypadku zrealizowałbym z wykorzystaniem obydwu portów sterownika. Twój PLC ma dwa porty komunikacyjne, więc nad czym się zastanawiać?
Może i jest wtedy trochę zabawy przy programowaniu (trzeba się przepinać żeby podpiąć komputer), ale przecież w systemie docelowym żadnego przepinania już nie będzie...
Chciałbym też zauważyć, że obsługa komunikacji w tych Fanucach jest nieco upierdliwa, wszystko trzeba realizować bloczkiem COMM_REQ.

Wracam po długim okresie posuchy.

Mam już pełen hardware "na stole": PLC, HMI, FI.

Aktualny plan, to zwalczyć komunikację po Modbus między tymi trzema urządzeniami, gdzie:
PLC - Master,
HMI, FI - Slave.

Rzeczywiście - pisanie komunikacji jest bardzo upierdliwe.
Wszystko wykonuje odpowiednio parametryzowany i wywoływany blok COMM_REQ.

Jak tylko rozwiążę to zagadnienie, dam znać na forum.
W przypadku problemów z panelem jako Slave, wykorzystam ewentualnie drugi port PLC.

Do gregor__
Jeśli chciałbyś podłączyć się tym panelem do PLC Fatek, to sprawdź driver wbudowany w EB8000.
Ewentualnie możesz go ściągnąć tutaj.