'Inteligenty' dom ze sterownikiem PLC

 Language:
Szukanie zaawansowane  

Aktualności:

Powrót do strony głównej: www.edom-plc.pl

Autor Wątek: WebVisu - czas reakcji  (Przeczytany 7727 razy)

abdenago

  • Newbie
  • *
  • Wiadomości: 12
    • Zobacz profil
WebVisu - czas reakcji
« dnia: Marca 18, 2018, 08:49:08 pm »

Cześć,

Na stronie https://www.edom-plc.pl/index.php/pl/wiecej-o-plc/funkcje/186-jeszcze-jeden-sposob-komunikacji-z-plc admin w jak zwykle przystępny sposób opisał działanie rozwiązania Franka Benkerta wraz z możliwością jego zatosowania. Mam jednak problem - czas w jakim pobierane są informacje o wartościach zmiennych.
Według opisu w artykule, przykładowy skrypt zakończył się i podał wynik w 0.2 sekundy. U mnie ten sam skrypt wykonuje się 4 sekundy. Podobnie jak otworzę stronę z wizualizacją, system reaguje na co dziesiąte kliknięcie na przycisk, a po zmianie stanu informuje też ze znacznym opóźnieniem. Gdy zmieniam wartość zmiennej w kodzie wszystko idzie od razu, również operacje (póki co zupełnie nieskomplikowane) jakie wykonuje sam PLC reagując na stan wejść wykonywane są natychmiastowo. Przebiłem się przez menu, ustawienia, forum, internet i nie mam pojęcia co to może być. Spotkał się może któryś z kolegów z podobną sytuacją? zinterfejsowanie tak działającego połączenia mija się z celem, użytkownicy mnie zabiją jak będą chcieli zapalić światło inaczej niż z przycisku :)
Zapisane

admin

  • Administrator
  • Sr. Member
  • *****
  • Wiadomości: 313
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #1 dnia: Marca 19, 2018, 09:29:15 am »

Cześć,

trudna sprawa tak orzec, czemu są lagi.  Jaką masz konfigurację?  Gdzie umieszczone są pliki?  Jakie masz czasy odpowiedzi, gdy pingujesz serwer, PLC i PLC z serwera?
Zapisane

abdenago

  • Newbie
  • *
  • Wiadomości: 12
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #2 dnia: Marca 19, 2018, 03:22:41 pm »

Hej,

Wszystko robie lokalnie, czasy odpowiedzi w okolicach 0.500ms więc nie ma tu problemu.
Zauważyłem gdy zaloguję się z codesys i odpalę run, to w okienku tasks obok zadań naliczane są wartości. Nie wnikałem jeszcze czym one są, podejrzewam, że kolejną iteracją wykonania danego tasku. Mam skonfigurowane 3 takie taski: podstawowy, obsługę satel integra (na podstawie innego wątku z forum) oraz komunikację z innym sterownikiem - slave. Po odpaleniu run widzę, że taski "zacinają" się właśnie co kilka sekund na kilka sekund. Poszperam dzisiaj, uproszczę wszystko, pousuwam dodatkowe taski i napiszę czy to ma związek.
Zapisane

admin

  • Administrator
  • Sr. Member
  • *****
  • Wiadomości: 313
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #3 dnia: Marca 19, 2018, 06:13:42 pm »

to tylko dorzucę, żeby ostrożnie podchodzić do częstotliwości wykonywania pobocznych procesów i, jeśli to nie konieczne, nie puszczać ich w trybie freewheeling. Ponadto uważaj na priorytety - proces główny to 1, ale Satel może być i 30...
Zapisane

abdenago

  • Newbie
  • *
  • Wiadomości: 12
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #4 dnia: Marca 19, 2018, 06:36:02 pm »

Tak miałem ustawione - satel był w ostatniej kolejności odśnieżania.
Zrobiłem inaczej, wyczyściłem sterownik przy pomocy funkcji online -> reset (original), widzę po FTP że usunął wszystkie pliki programu, napisałem nowy programik z 4 zmiennymi, obsługującymi dwa dwuwejściowe moduły wejścia i wyjścia, zrobilem jeden przycisk zmieniający wartość wyjścia na false, gdy wejście jest false, i odwrotnie - prościej się nie da. mimo to działa tak samo, odczytanie webvisu trwa 4 sekundy, a wizualizacja tnie. W trybie symulacji oczywiście wszystko ladnie chodzi. Więc musi coś być w samym sterowniku. Czy wiecie może czy jest możliwość przywrócenia całości do ustawień fabrycznych?
Zapisane

vakul

  • Full Member
  • ***
  • Wiadomości: 149
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #5 dnia: Marca 19, 2018, 06:40:28 pm »

W zakładce Resources wybierz PLC Browser.
Wpisz: "login admin wago" [enter]
następnie wpisz: "tsk" [enter]

dostaniesz informacje na temat swoich tasków i rzeczywistego czasu ich działania. Tu znajdziesz problem.

Tak jak wspomniał admin, używaj tylko trybu "cyclic" w taskach. Czas jaki tam ustawisz musi być dłuższy niż wymagany przez dane zadanie.

Przykład moich tasków:
PLC_PRG()  (priority 4, T#30ms) - takie zalecenie dostałem kiedyś z wago.
Aktualizacja zmiennej czasu (priority 20, T#500ms)
MySql (priority 31, T#300ms) - tu spokojnie można dać więcej

Kolejna sprawa jest taka, że Twój sterownik ma tylko jeden procesor, który zajmuje się wszystkim w tym także obsługą sieci ethernet, a ta ma niski priorytet. Jeżeli coś istotnie zajmuje sterownik, to ethernet idzie w odstawkę.

W konsekwencji powyższego - nie korzystaj ze switcha w sterowniku (sterownik 750-88x), zajmujesz cenny czas procesora. Najlepiej wyłączyć 2 port sterownika (przez interfejs webowy).

Zapisane

abdenago

  • Newbie
  • *
  • Wiadomości: 12
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #6 dnia: Marca 19, 2018, 07:33:08 pm »

Dzięki, takich informacji potrzebowałem :)
Jednak to nie to - po napisaniu najprostrzego programu na świecie problem nadal wystepował.
Postanowiłem się douczyć, i znalazłem - jako zmienną przypisaną do przycisku ustawiałem bezpośrednio zmienną przypisaną do wejścia/wyjścia w danym module. Gdy zadeklarowałem własne zmienne typu bool i jedną z nich przypisałem do przycisku - zaczęło działać od razu. ta kwestia rozwiązana. Pozostaje temat długiego wykonywania się skryptu, może wkleję poniżej jego treść oraz wynik (przepraszam z góry za śmiecenie):

root@raspberrypi:~# cat skrypt.py
#!/usr/bin/python
import requests     #you might need to install requests separatelly
req = "|0|100"
for num in range (0,99):
        req+= "|"+str(num)+"|2|"+str(num)+"|1|2"
req+= "|"
r = requests.post('http://10.0.0.100/PLC/webvisu.htm', data=req)
print r.text
root@raspberrypi:~# ./skrypt.py
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|

oczywiście mam tylko jedną zmienną. Gdy zmienię jej wartość na true, pierwsze zero staje sie jedynką.
Gdy w skrypcie ustawię, żeby pobierał tylko jedną zmienną - i tak działa ok 4 sekund.
Zapisane

abdenago

  • Newbie
  • *
  • Wiadomości: 12
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #7 dnia: Marca 19, 2018, 11:14:26 pm »

Znalazłem przyczynę. Po chwilach walki z pythonem postanowiłem spróbować wersję jQuery, która zadziałała idealnie i od razu! Jednak python nie dawał mi spokoju. Okazało się, że problemem jest moduł requests, który spowalnia całość. Miejsce które naprowadziło mnie na rozwiązanie:
https://github.com/requests/requests/issues/4278
Po zainstalowaniu wcześniejszej wersji requests zaczęło działać kilka razy szybciej :)
Dziękuję za pomoc, myślę, że temat rozwiązany.
Zapisane

mkochniarczyk

  • Newbie
  • *
  • Wiadomości: 15
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #8 dnia: Marca 25, 2018, 07:24:14 pm »

Panowie a jakie macie czasy odpowiedzi przy takim połączeniu z PLC ?
Zapisane

abdenago

  • Newbie
  • *
  • Wiadomości: 12
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #9 dnia: Marca 26, 2018, 04:40:18 pm »

root@raspberrypi:~# ping 192.168.66.15 -c 8
PING 192.168.66.15 (192.168.66.15) 56(84) bytes of data.
64 bytes from 192.168.66.15: icmp_seq=1 ttl=64 time=0.623 ms
64 bytes from 192.168.66.15: icmp_seq=2 ttl=64 time=0.659 ms
64 bytes from 192.168.66.15: icmp_seq=3 ttl=64 time=0.617 ms
64 bytes from 192.168.66.15: icmp_seq=4 ttl=64 time=0.655 ms
64 bytes from 192.168.66.15: icmp_seq=5 ttl=64 time=0.634 ms
64 bytes from 192.168.66.15: icmp_seq=6 ttl=64 time=0.634 ms
64 bytes from 192.168.66.15: icmp_seq=7 ttl=64 time=0.615 ms
64 bytes from 192.168.66.15: icmp_seq=8 ttl=64 time=0.593 ms

--- 192.168.66.15 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7270ms
rtt min/avg/max/mdev = 0.593/0.628/0.659/0.036 ms
Zapisane

abdenago

  • Newbie
  • *
  • Wiadomości: 12
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #10 dnia: Marca 26, 2018, 04:45:20 pm »

webvisu.html odpowiada średnio w czasie 85ms
Zapisane

blackbox

  • Newbie
  • *
  • Wiadomości: 27
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #11 dnia: Marca 28, 2018, 10:10:35 pm »

W zakładce Resources wybierz PLC Browser.
Wpisz: "login admin wago" [enter]
następnie wpisz: "tsk" [enter]

dostaniesz informacje na temat swoich tasków i rzeczywistego czasu ich działania. Tu znajdziesz problem.

Tak jak wspomniał admin, używaj tylko trybu "cyclic" w taskach. Czas jaki tam ustawisz musi być dłuższy niż wymagany przez dane zadanie.

Przykład moich tasków:
PLC_PRG()  (priority 4, T#30ms) - takie zalecenie dostałem kiedyś z wago.
Aktualizacja zmiennej czasu (priority 20, T#500ms)
MySql (priority 31, T#300ms) - tu spokojnie można dać więcej

Czy w takim razie mając jedno zadanie główne (PLC_PRG) i kilka pobocznych (ReadTime, Satel, Modbus) lepiej jest:
1) ustawić wszystkie zadania jako zadania cykliczne (główne z najwyższym priorytetem), czy
2) zadanie główne ustawić jako zadanie freewheeling (z najwyższym priorytetem) a pozostałe jako cykliczne - tak mam obecnie.

Poniżej zrzut czasów moich zadań:

Number of Tasks: 4
Task 0: Main,  ID: 0
   Cycle count: 142752340
   Cycletime:       1 ms
   Cycletime (min): 1 ms
   Cycletime (max): 9 ms
   Cycletime (avg): 1 ms
   Status: RUN
   Mode:   UNHANDLED
   ----
   Priority:  1
   Intervall: 0 ms
   Event:     NONE
   ----
   Function pointer: 16#28D19244
   Function index:   116


Task 1: UpdateClock,  ID: 1
   Cycle count: 115161
   Cycletime:       75 ms
   Cycletime (min): 2 ms
   Cycletime (max): 2550 ms
   Cycletime (avg): 365 ms
   Status: RUN
   Mode:   UNHANDLED
   ----
   Priority:  3
   Intervall: 5000 ms
   Event:     NONE
   ----
   Function pointer: 16#28D19340
   Function index:   119


Task 2: MB_RTU_MASTER_TASK,  ID: 2
   Cycle count: 41049117
   Cycletime:       5 ms
   Cycletime (min): 1 ms
   Cycletime (max): 110 ms
   Cycletime (avg): 9 ms
   Status: RUN
   Mode:   UNHANDLED
   ----
   Priority:  2
   Intervall: 5 ms
   Event:     NONE
   ----
   Function pointer: 16#28D19298
   Function index:   117


Task 3: Satel,  ID: 3
   Cycle count: 1145948
   Cycletime:       1 ms
   Cycletime (min): 1 ms
   Cycletime (max): 2241 ms
   Cycletime (avg): 133 ms
   Status: RUN
   Mode:   UNHANDLED
   ----
   Priority:  5
   Intervall: 500 ms
   Event:     NONE
   ----
   Function pointer: 16#28D192EC
   Function index:   118
Zapisane

vakul

  • Full Member
  • ***
  • Wiadomości: 149
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #12 dnia: Marca 29, 2018, 11:12:14 pm »

Wszystko ustaw jako Cyclic, nie używaj Freewheeling.

Proponowałbym tak:
PLC_PRG(), priority 4, 30ms
UpdateClock, priority 25, 500ms (nie 5000!)
MB_RTU_MASTER_TASK - priority 20, 100 ms (średni czas masz 9ms, nie ustawiaj więc wykonania co 5ms)
Satel, priority 26, 500ms

Ten Twój UpdateClock jakoś  podejrzanie długo się wykonuje. Co tam w nim robisz?
Zapisane

blackbox

  • Newbie
  • *
  • Wiadomości: 27
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #13 dnia: Marca 30, 2018, 09:28:53 am »

Wszystko ustaw jako Cyclic, nie używaj Freewheeling.

Proponowałbym tak:
PLC_PRG(), priority 4, 30ms
UpdateClock, priority 25, 500ms (nie 5000!)
MB_RTU_MASTER_TASK - priority 20, 100 ms (średni czas masz 9ms, nie ustawiaj więc wykonania co 5ms)
Satel, priority 26, 500ms

Ten Twój UpdateClock jakoś  podejrzanie długo się wykonuje. Co tam w nim robisz?

Zmieniłem i teraz jest OK. Od razu widać różnicę w repsonsywności webvisu. W dokumentacji oczywiście wszystko jest napisane:

The "freewheeling" task call option is not suitable in conjunction
with the "WebVisu"; as in this case, the high-priority PLC program suppresses the
web server. Instead of this, use the "cyclic" task call option with a realistic value.

W zadaniu UpdateClock, oprócz odczytu aktualnego czasu była wywołana funkcja sprawdzająca jaka jest taryfa prądu - na razie jej nie uzywam, więc usunąłem ją, został więc tylko odczyt czasu.

Aktualne czasy:
Number of Tasks: 4
Task 0: Main,  ID: 0
   Cycle count: 61066
   Cycletime:       1 ms
   Cycletime (min): 1 ms
   Cycletime (max): 7 ms
   Cycletime (avg): 1 ms
   Status: RUN
   Mode:   UNHANDLED
   ----
   Priority:  4
   Intervall: 30 ms
   Event:     NONE
   ----
   Function pointer: 16#28D19244
   Function index:   116


Task 1: UpdateClock,  ID: 1
   Cycle count: 3664
   Cycletime:       3 ms
   Cycletime (min): 2 ms
   Cycletime (max): 13 ms
   Cycletime (avg): 4 ms
   Status: RUN
   Mode:   UNHANDLED
   ----
   Priority:  25
   Intervall: 500 ms
   Event:     NONE
   ----
   Function pointer: 16#28D19340
   Function index:   119


Task 2: MB_RTU_MASTER_TASK,  ID: 2
   Cycle count: 18321
   Cycletime:       1 ms
   Cycletime (min): 1 ms
   Cycletime (max): 90 ms
   Cycletime (avg): 1 ms
   Status: RUN
   Mode:   UNHANDLED
   ----
   Priority:  20
   Intervall: 100 ms
   Event:     NONE
   ----
   Function pointer: 16#28D19298
   Function index:   117


Task 3: Satel,  ID: 3
   Cycle count: 3665
   Cycletime:       1 ms
   Cycletime (min): 1 ms
   Cycletime (max): 8 ms
   Cycletime (avg): 1 ms
   Status: RUN
   Mode:   UNHANDLED
   ----
   Priority:  26
   Intervall: 500 ms
   Event:     NONE
   ----
   Function pointer: 16#28D192EC
   Function index:   118
Zapisane

vakul

  • Full Member
  • ***
  • Wiadomości: 149
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #14 dnia: Marca 30, 2018, 05:31:02 pm »

Teraz wszystko wygląda ok.

To sprawdzanie taryfy to pewnie raz na minutę by wystraczyło. Nie jest to raczej informacja krytyczna jak się domyślam. Zrób na to osobnego taska i po sprawie.

Modbusa RTU możesz trochę zwiększyć, chyba że potrzebujesz danych z magistrali "na już". Moduł RSa ma swój bufor i nie ma większego znaczenia czy czytasz go co 100ms czy 1000ms. Dane będą tam czekały.
Zapisane

mkochniarczyk

  • Newbie
  • *
  • Wiadomości: 15
    • Zobacz profil
Odp: WebVisu - czas reakcji
« Odpowiedź #15 dnia: Marca 30, 2018, 06:34:03 pm »

webvisu.html odpowiada średnio w czasie 85ms
A odświeżenie całej strony?
Zapisane