Komunikacja z serwem (Digital Inputs + Modbus)

[Jakub_Skotnicki]

Dzień dobry,
Próbuje uruchomić aplikację z udziałem:

PLC V1040-T20B
Port Ethernet V200-19-ET2
i serwo falownik ABB MicroFlex e190

Działanie ma polegać na tym, że PLC wysyła informację do serwa na jaką pozycję ma dojechać silnik i czeka na informację zwrotną o osiągniętej pozycji.

Założenie było takie, że komunikacja będzie odbywała się wyłącznie przez Modbus TCP ale niestety okazało się to o wiele trudniejsze niż zakładałem. (Gdy ponownie wrócę do tematu opiszę problemy na forum).

Postanowiłem wykorzystać cyfrowe wejścia i wyjścia serwa.

Pozycja na której ma się znaleźć silnik wysyłana jest przez modbus.
Gdy dostanę potwierdzenie, że udało się wysłać dane do serw odnośnie pozycji wystawiam stan wysoki na wyjście PLC O53 z 0,5sek opóźnieniem
Serwo w swoim kodzie reaguje uruchomieniem procedury jazdy na pozycję
Czekam na sygnał zwrotny od serwa na wejściu I62 od serwa
Zboczem narastającym tego wejścia kończę procedurę uznając że serwo jest na pozycji

Mój problem polega na tym, że czasami wykonanie utyka w procedurze wysłania pozycji do serwa. Wystawiany jest stan wysoki na wyjście O53, ale pojawiający się stan wysoki na wejściu I62 jak by nie przerywał wykonania procedury

Komunikację z serwem zamknąłem w subrutynie, która jest wywoływana w różnych miejscach w kodzie, w sytuacji, gdy trzeba wysłać serwo za zadaną pozycję.
Główna część programu to sekwencje które mają wykonywać się automatycznie, jedna po drugiej. Aby zachować kolejność używam countera.
Po każdym wykonanym etapie dokonuję incrementu countera, a przed wykonaniem kolejnego sprawdzam, czy counter ma już wartość numeru etapu który ma się wykonać.

Załączam dwa screeny. Miejsce wywołania procedury odczytu z serwa oraz subrutynę odpowiedzialną za wysyłanie pozycji serwa .

Kodu nie mogę załączyć bo dostaje komunikat "rozszerzenie VLP jest zablokowane"

Bardzo proszę o wskazówki, w czym może leżeć problem i czego ewentualnie spróbować. Chciałbym też wiedzieć czy:
Sposób wykonywania kolejnych kroków za pomocą countera jest poprawny
Czy sposób w jaki dodałem opóźnienia pomiędzy wykonaniem się kolejnych etapów jest ok
W jaki sposób najlepiej sprawdzić, czy komunikacja z serwem została nawiązana i czy dane wysłane.

Z góry dziękuję za pomoc

[Mateusz Sikorski]

Witam,
proszę spakować plik VLP do RAR lub ZIP i wtedy wysłać. Po samych zdjęciach nie jestem w stanie stwierdzić w 100%, gdzie może leżeć błąd.
Napisał Pan, że:

Mój problem polega na tym, że czasami wykonanie utyka w procedurze wysłania pozycji do serwa. Wystawiany jest stan wysoki na wyjście O53, ale pojawiający się stan wysoki na wejściu I62 jak by nie przerywał wykonania procedury

Co należy rozumieć przez procedurę? Chodzi o bit MB34, że jest ustawiony na "1" zamiast "0"? A może chodzi o MB36?
Nie widzę również, gdzie załączany jest T4 (jeżeli w ogóle jest).

Sposób wykonywania kolejnych kroków za pomocą countera jest poprawny

Osobiście nie używam zmiennych C, zamiast tego wolę MI, ale nie widzę żadnego błędu przy wykorzystaniu tej zmiennej.

Czy sposób w jaki dodałem opóźnienia pomiędzy wykonaniem się kolejnych etapów jest ok

Jeżeli używa Pan Timer'ów Extended (TE) to nie musi Pan resetować ich po wykryciu zbocza opadającego danego T:
https://unitronicsplc.com/Download/SoftwareHelp/VisiLogic_Knowledgebase/Ladder/Operands/Timers.htm

W jaki sposób najlepiej sprawdzić, czy komunikacja z serwem została nawiązana i czy dane wysłane.

Jeżeli chodzi o Modbus TCP to w bloku Modbus TCP Configuration, który należy zastosować ma Pan tzw. bit zajętości sieci, który powinien być "0", jeżeli nie wysyła Pan żadnego zapytania do serwa.
Przy każdym zapytaniu (bloku Modbus TCP do wysyłania żądania odczytu lub zapisu) wybiera Pan zmienną tzw. Status Messages, który po wysłaniu takiego żądania powinien przyjmować wartość 0 <- wtedy wszystko OK. Jeżeli jest inna wartość tzn., że gdzieś jest błąd.
Oczywiście najpierw należy połączyć się z urządzeniem Slave za pomocą bloku TCP/IP Connect.

[Jakub_Skotnicki]

W załączniku spakowany program.

Pisząc "utyka w procedurze" miałem na myśli, że nie wywołuje się Net6 z subrutynu, który ustawia MB34 na stan wysoki.

Przez co counter C0 w procedurze nadrzędnej nie zostaje zinkrementowany.

[Jakub_Skotnicki]

Uzupełniając, T4 pełnił rolę timeoutu. Jeśli serwo nie wystawiło stanu wysokiego na wejście PLC I62 to po czasie T4 miał się wyresetować MB34, aby program mógł iść dalej (zrobione dla testu gdzie leży problem) Aktualinie T4 jest odłączone i nie jest używane.

[Mateusz Sikorski]

Czy podczas "utknięcia w procedurze":
1) MB12 jest "1" czy "0"?
2) Czy I62 jest "1" czy "0", może I62 nie zeruje się, dlatego nie ma zbocza narastającego?

Czy zawsze w tym samym miejscu "utyka procedura"? Chodzi mi o wartość C0.
Prosiłbym jeszcze o dodanie do net #6 w tej subrutynie za zboczem narastającym I62 bloku INC z wolnym rejestrem MI (dowolnym), w celu zweryfikowania pkt.2, który zadałem wyżej.

Odnośnie T4 - OK, wszystko jasne <- na pewno nie ma znaczenia.

[Jakub_Skotnicki]

Czy oba zapisy z załącznika są dozwolone i działają w ten sam sposób?

PS. Tak jak Pan pisałem, reset na końcu nie potrzebny, nie zdążyłem usunąć

[Mateusz Sikorski]

W obu przypadkach algorytm zadziała tak samo i wg mnie jest to dozwolone.

[Jakub_Skotnicki]

Czy podczas "utknięcia w procedurze":
1) MB12 jest "1" czy "0"?

MB12 = 1

2) Czy I62 jest "1" czy "0", może I62 nie zeruje się, dlatego nie ma zbocza narastającego?

Kod po stronie serwa wygląda tak, że stan wysoki na I62 PLC jest cały czas aż do momentu wystawienia wyjścia O53. Jak to na stąpi, serwo zeruje I62 i sygnał pojawia się ponownie gdy zostanie wykonana odpowiednia operacja w serwie. Serwo tego sygnały nie zdejmuje nigdy, jeśli nie dostanie sygnału na wejście z O53.

Czy zawsze w tym samym miejscu "utyka procedura"? Chodzi mi o wartość C0.

Przeważnie przy pierwszym wywołaniu subrutyny, czyli od razu (Counter w T1 = 3), ale nie zawsze, zdarzało się, że przeszedł dalej i dopiero na kolejnych krokach utykał.

Prosiłbym jeszcze o dodanie do net #6 w tej subrutynie za zboczem narastającym I62 bloku INC z wolnym rejestrem MI (dowolnym), w celu zweryfikowania pkt.2, który zadałem wyżej.

Dodałem dwie zmienne. Jedną w miejscu gdzie wystawiane jest o53 oraz drugą gdzie powinno pojawić się I62.



Otrzymałem wynik którego kompletnie nie rozumiem.

Jeśli timer TE6 ustawiony jest na 0,5sek to wynik jest jak poniżej:


Okazuje się, że nie wystawiane jest O53 więc żadna kolejna linia kodu się nie wywoła.

Następnie zmieniłem TE6 na 1sek. i program zrobił kilkadziesiąt cykli ani razu się nie zawieszając:

[Mateusz Sikorski]

Proszę jeszcze sprawdzić jak zachowuje się C0 oraz DW3. W Pańskim programie setowanie MB36 zależy właśnie od tego, że DW3 musi być różne od zera.

[Jakub_Skotnicki]

Udało mi się zlokalizować problem. Jak pisałem wcześniej, PLC wystawiał sygnał na wejście serwa w oczekiwaniu wykonania danej czynności. Gdy serwo otrzymało sygnał na wejście, resetowało swoje wyjście i po wykonaniu akcji ponownie je ustawiało na 1.

Okazało się, że w niektórych przypadkach zmiana z 1 na 0 i ponownie na 1 wykonywała się tak szybko po stronie serwa, że PLC nie był w stanie wyłapać zmiany. Dodanie opóźnienia pomiędzy ponownym wystawieniem 1 w programie serwa pomogło.

Dziękuję za podpowiedzi. Pomogły w diagnozie.