Elektroda.pl
Elektroda.pl
X

Search our partners

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

S7-1200 - Cyclic interuption (OB30)

kornik280 02 Jul 2013 07:07 4023 21
SterControl
  • #1
    kornik280
    Level 18  
    Witam

    Jeśli chcę wykorzystać Modbus RTU (lub TCP) do odpytywania jakiś urządzeń z częstotliwością powiedzmy co 2sekundy, to czy poprawne jest używanie do tego cyklicznego przerwania? Mam namyśli umieszczanie w ob30 bloczka modbus master?
  • SterControl
  • #2
    jestam
    Automation specialist
    Nie jest poprawne.

    Nienaruszalna zasada nr 1. Nie używaj przerwań.
    Nienaruszalna zasada nr 2. Jeśli naprawdę nie masz pomysłu jak rozwiązać problem bez przerwań, zastosuj nienaruszalną zasadę nr. 1. :)

    Użyj timera, który będzie aktywował wymianę Modbus. Pamiętaj, że wymiana (szczególnie RTU) może chwilę trwać - upewnij się, że poprzednia się zakończyła, zanim aktywujesz następną.

    (powyższe dotyczy sterowników PLC wszystkich producentów)
  • #3
    kishon
    Level 14  
    Na szkoleniu jakie miałem z s7-1200 prowadzący mówił o tym aby regulator PID właśnie umieszczać w przerwaniach.

    Czym jest podyktowana nienaruszalna zasada nr 1 i 2??
  • SterControl
  • #4
    jestam
    Automation specialist
    Regulator PID powinien być wykonywany w stałym cyklu, wahania mogą pogorszyć jakość regulacji. W dodatku czas cyklu powinien być wystarczająco krótki (ile to jest "wystarczająco krótko", zależy od obiektu).

    Zazwyczaj czas wykoniania kolejnych cykli PLC się zmienia zależnie np. od skoków w programie (pomijanie niektórych instrukcji). Można ustawić tzw. "stały czas cyklu", wtedy - jeśli program się skończy wcześniej - to sterownik czeka z rozpoczęciem kolejnego cyklu. Problem się pojawia, gdy regulator potrzebuje być wykonany np. co 50 ms, a max. czas cyklu może być (lub zawsze jest) dłuższy.

    Wtedy może mieć sens uruchomienie go na przerwaniu. Trzeba pamiętać o odczytaniu aktualnych stanów wejść na początku kodu obsługi przerwania i zapisaniu wyniku na wyjście na końcu. We/wy oczywiście tylko lokalne - taka zabawa nie ma sensu przy przesyle danych przez sieć.

    Ja bym zaczął od próby redukcji cyklu, ew. zastosował mocniejszy sterownik.

    kishon wrote:
    Czym jest podyktowana nienaruszalna zasada nr 1 i 2??

    Sterowniki pracują jednowątkowo. Przerwania wprowadzają współbieżność - przerwanie może się pojawić w dowolnym momencie. Współbieżność jest niebezpieczna, szczególnie gdy programista nie ma jej "w głowie" od samego początku tworzenia programu. Np. jeśli kod przerwania współużytkuje jakieś dane ze "zwykłym" kodem wykonywanym w cyklu PLC, to może się okazać, że przerwanie zostanie aktywowane w trakcie modyfikacji danych przez "zwykły" kod PLC.

    To otwiera wielką puchę Pandory pełną problemów, które pojawiają się tylko czasami - program wydaje się działać, ale kiedyś tam może się wywrócić.

    Kod uruchamiany przerwaniem nie powinien być zależny od czegokolwiek "na zewnątrz".
    Tylko jak to zrobić, skoro nawet ten PID wymaga nastaw?

    PID na przerwaniu to powinna być ostatnia deska ratunku, a nie standardowe rozwiązanie powielane jak leci bez zastanowienia. Moim zdaniem, oczywiście.
  • #5
    Rariusz
    Automation specialist
    Witam

    jestam wrote:
    Np. jeśli kod przerwania współużytkuje jakieś dane ze "zwykłym" kodem wykonywanym w cyklu PLC, to może się okazać, że przerwanie zostanie aktywowane w trakcie modyfikacji danych przez "zwykły" kod PLC.


    Gdzie jest napisane to co kolega napisał?. Rozumiem omówiony problem
    jednak jestem ciekaw czy faktycznie któryś z producentów
    tak napisał.

    Pozdrawiam,
  • #6
    jestam
    Automation specialist
    Takie rzeczy napisane są w podręcznikach programowania współbieżnego. Np. Ben-Ari czy wielu innych.

    Producenci PLC, które znam, zazwyczaj pomijają temat przerwań milczeniem, lub piszą coś ogólnikowego w rodzaju "obsługa przerwania powinna być jak najkrótsza, żeby za bardzo nie wydłużać cyklu sterownika". Nic o synchronizacji.

    Wspomniana ogólna wskazówką jest poprawna - jeśli mamy dwa przerwania obsługiwane przez 0,1 ms z cyklem 15 ms i 25 ms, to ich wpływ na czas cyklu jest pomijalny; jeśli ich obsługa trwa po 5 ms to cykl wydłuża się ponad dwukrotnie; ale jeśli te przerwania potrzebują po 8,5 ms czasu obsługi, to... mamy problem. Zresztą to się da policzyć.
  • #7
    Rariusz
    Automation specialist
    Witam

    jestam wrote:
    Takie rzeczy napisane są w podręcznikach programowania współbieżnego. Np. Ben-Ari czy wielu innych.


    Tak, jest to opisane w tego typu podręcznikach. Jednak ciekawiło mnie
    czy któryś z producentów piszę coś poza tym że:

    Quote:
    obsługa przerwania powinna być jak najkrótsza, żeby za bardzo nie wydłużać cyklu sterownika


    Obecnie pisze program na sterownik CompactLogix w którym
    wykorzystuję kilka zadań. Jedne zadanie wykorzystywane jest do
    wyliczania rampy i obliczona wartość zapisywana jest do struktury
    regulatora PID jak wartość SP. Kolejno w drugim zadaniu
    znajduje się obsługa regulatora PID, która wykorzystuje
    parametr SP obliczony z poprzedniego zadania dla rampy.
    Zasób jest dzielony pomiędzy dwoma zadaniami. Zrobiłem
    tak ponieważ takie rozwiązanie było w programie wzorcowym.
    W tym przypadku regulator PID wykorzystywany jest do
    sterowania temperaturą w piecu. Proces jest wolno
    zmienny więc myślę, że dzielony zasób przez dwa zadana
    w tym przypadku nie ma znaczenia. Jeśli proces byłby
    szybko zmienny to mogły by zaistnieć problemy jednak
    nigdy nie słyszałem o tego typu problemach.

    Chętnie poczytam informację oraz uwagi na ten temat
    od osób, które się spotkały z takim problemem.


    Pozdrawiam
  • #8
    kornik280
    Level 18  
    W takim razie do czego stosuje się cykliczne przerwanie w praktyce?
  • #9
    Rariusz
    Automation specialist
    Witam,

    Zastanawia mnie fakt dzielenia zasobów przez zadania i napisze
    moje uwagi.

    1. We wcześniejszym poście użyłem określenie zadania co jest błędem.
    przerwanie to nie to samo co zadanie (watek, task itd).

    2. Moim zdaniem zdarzenia a programowanie współbieżne to dwie
    różne rzeczy choć mogę się mylić.

    3. Jeżeli w programie głównym PLC MAIN robimy przypisanie wartości
    do zmiennej np. i = 10 i w tym momencie nastąpi przerwanie
    to:
    a) procesor zapamięta kontekst programu i przejdzie do obsługi przerwania?,
    b) dokończy wykonywanie przypisania wartość i dopiero przejdzie do
    obsługi przerwania. Inaczej mówiąc czy może przerwać przypisywanie
    wartość w trakcie jej wykonywania?

    W programowaniu współbieżnym mamy do czynienia z podzielnością
    instrukcji, pytanie czy coś takiego ma miejsce w przypadku korzystania
    z przerwań?.


    Nie zapominajmy że są jeszcze priorytety.

    Pozdrawiam,
  • #10
    jestam
    Automation specialist
    Wątek nam się rozszczepił na dwa :) Będzie długo.

    kornik280 wrote:
    W takim razie do czego stosuje się cykliczne przerwanie w praktyce?

    Do ratowania sytuacji gdy absolutnie wszystko inne zawiedzie.
    Zwróć uwagę, że język asemblera (listy instrukcji) sterowników sprzed normy IEC61131-3 jest na bardzo niskim poziomie abstrakcji. Siemensowy STL tak naprawdę nie jest stworzony dla człowieka - maszyna stosowa jest wygodna dla tworzenia kompilatorów, ale bardzo nieefektywna w ręcznym pisaniu kodu. Dlaczego wszyscy w nim piszą to inna sprawa, zahaczająca o politykę i historię :)

    Rariusz wrote:
    pisze program na sterownik CompactLogix w którym
    wykorzystuję kilka zadań


    Nie znam Rockwella na tyle dobrze, żeby się tutaj autorytatywnie wypowiadać. Potraktuj wszystko co poniżej z pewną dozą ostrożności :)

    Rockwell programuje się w czymś podobnym do normy IEC 61131-3. W tym dokumencie opisana jest zgodność z normą. Na str. 10 jest napisane, że normowa koncepcja zadań ("Task") jest wspierana. Niestety, norma jest bardzo ogólna w temacie, jak to ma faktycznie działać. Twórca implementacji ma sporą dowolność.

    Rozdział 7 tego dokumentu rzuca trochę światła na zagadnienie.
    Obsługiwane jest max 8 Zadań (Task). Każde zadanie może mieć do 32 Programów (Programs) wykonywanych jeden po drugim. Tzn. nie ma współbieżności między Programami w jednym Zadaniu.

    Zadania mają priorytety i mogą się nawzajem wywłaszczać (tab. 25 i rysunek na str. 100).

    W dokumencie jest wspomniane, że może zabraknąć czasu na wykonanie zadań o niższych priorytetach, jeżeli te o wyższych zużyją cały dostępny czas procesora, ale nie widzę, żeby opisano jak to liczyć.

    Jeśli dwa zadania odwołują się do tych samych zmiennych globalnych - to mogą wystąpić wszystkie znane problemy. Nie widzę ani słowa na ten temat. Nie widzę także żadnych bloków do synchronizacji (typu semafory). Norma nie wymaga, producent PLC ma wolną rękę. Nawet gdyby semafory były dostępne, to pojawia się jeszcze problem inwersji priorytetów. Nic na ten temat nie widzę.

    Jeśli w jednym zadaniu piszesz do SP regulatora PID, a w drugim liczysz regulator, to wszystko może wybuchnąć w twarz - ale nie musi. Najgorszy scenariusz (przykładowo):
    - Zadanie A rozpoczyna wykonanie bloku funkcyjnego PID, kod otrzymuje referencję do struktury danych, odczytuje SP, liczy, liczy if SP > X then, ....
    - Zadanie B wywłaszcza zadanie A, zapisuje nową wartość SP' do struktury danych PID - tej samej, której używa PID, i kończy wykonanie
    - Zadanie A wykonuje gałąź then, czyli wie że SP > X, więc liczy (unsigned) d = SP' - X - teraz używa nowej wartości zapisanej w miejscu SP, która to wartość przypadkiem jest mniejsza od X, więc d jest ujemne - ale d jest traktowane jako liczba bez znaku - ups....

    Trochę lepszy: PID zakodowano tak, że na początku wykonania bloku wszystkie wartości ze struktury danych są kopiowane do zmiennych lokalnych. Obliczenia są wykonywane na zmiennych lokalnych, nowe wartości zapisywane w strukturze dopiero na końcu obliczeń. Szansa, że wszystko się wysypie maleje, ale to nadal nie jest poprawny program.

    Jeśli wszystkie operacje na zmiennych globalnych są atomowe, w takim sensie, że każda zmienna globalna jest niezależna od wszystkich innych, to może w miarę działać. Jeśli są jakiekolwiek zależności, np. takie, że zawsze X+Y = 10 (czyli zawsze jest wykonane X := cośtam, Y := 10 - X), ups... Zrób bufor kołowy bez zależności między głową i ogonem :)

    Nie twierdzę że się nie da (na ratunek przychodzą np. nieblokujące algorytmy synchronizacji), ale lepiej się w to bagno nie pchać bez naprawdę dobrego powodu.

    Rariusz wrote:
    Zrobiłem tak ponieważ takie rozwiązanie było w programie wzorcowym.

    Programy przykładowe rzadko są dobrymi wzorami. Tutaj można znaleźć wiele takich przypadków :)
    Dlaczego nie można umieścić tego kodu w jednym Zadaniu?

    Rariusz wrote:
    Jeśli proces byłby szybko zmienny to mogły by zaistnieć problemy jednak nigdy nie słyszałem o tego typu problemach

    Odpowiednio szybki komputer ukrywa wiele problemów :) Możesz je łatwo zaobserwować odpowiednio konstruując kod w Zadaniach.

    Jest mała szansa, że natrafisz na taki problem podczas testowania programu na biurku, czy uruchamiając na obiekcie. W czasie życia systemu, jak coś się podzieje, to zapewne będzie przemijające i nie da się powtórzyć - więc ludzie to zignorują - chyba że coś wybuchnie ;). Takie błędy są praktycznie nieznajdowalne, nawet jeśli wiadomo że są w programie.

    Więc można problem zignorować lub zrobić to poprawnie bez współbieżności :)

    Rariusz wrote:
    1. We wcześniejszym poście użyłem określenie zadania co jest błędem.
    przerwanie to nie to samo co zadanie (watek, task itd).

    Niezupełnie błędem. Platformy (Simatic i IEC) są różne, ale przerwanie cykliczne OB30 to prawie to samo co zadanie (Task) cykliczne z normy. Przykładowo GE PacSystems ma przerwania i mogą mieć one priorytety i się wywłaszczać - albo nie, zależnie od konfiguracji.

    Rariusz wrote:
    2. Moim zdaniem zdarzenia a programowanie współbieżne to dwie
    różne rzeczy choć mogę się mylić.

    Masz na myśli "programowanie sterowane zdarzeniami"? (obecnie modne jako Reactive Programming, async itp.)? Tak, co coś zupełnie innego niż programowanie współbieżne.

    Mało tego, "współbieżne" diagramy sekwencji (SFC, Graph i podobne) mogą być (i zwykle są) wykonywane bez wielozadaniowości. I dobrze :)

    Rariusz wrote:
    Inaczej mówiąc czy może przerwać przypisywanie wartość w trakcie jej wykonywania?
    W programowaniu współbieżnym mamy do czynienia z podzielnością instrukcji, pytanie czy coś takiego ma miejsce w przypadku korzystania z przerwań?.


    To jest dokładnie to samo.

    Rozkazy fizycznego procesora są (w uproszczeniu) nieprzerywalne. I = 10 może być zrealizowane jako (Ładuj 10 do komórki pamięci I) - zapewne nieprzerywalne, ale może być też (Ładuj 10 na stos/do akumulatora; Zapisz szczyt stosu/akumulator do komórki pamięci I) - jak najbardziej przerywalne. Czy rozkazy listy instrukcji sterownika PLC są przerywalne "w trakcie" zależy od firmware - i w dodatku nie bardzo da się to sprawdzić, nie ma to też większego znaczenia.
  • #11
    adamac2
    Automation specialist
    Do Rariusza.

    Nie wiem dlaczego rozdzieliłeś wyliczanie SP oraz wywoływanie PID'a (dla mnie to raczej są to zadania ściśle powiązane :)).
    Ale na dwóch podprogramach to raczej nie zarżniemy CompactLogixa :).

    Te przerwania w twoim rozumieniu to podprogramy Periodic czy Event?

    A co do zastosowań przerwań to mogą być różne w AB:
    - obsługa PID, który liczy bliżej prawdy w Periodic Task niż Continous Task (wywołanie z stałym interwałem czasowym)
    - obsługa wejść oraz zadań Motion
    - obsługa wybranych wejść / zmiennych
    - programy na sterownikach redundantnych (zalecane że powinny być albo w continous albo w periodic, lepiej nie łączyć)
  • #12
    jestam
    Automation specialist
    adamac2 wrote:
    Ale na dwóch podprogramach to raczej nie zarżniemy CompactLogixa

    Zależy co one będą robić :) Odpowiednio szybki komputer...

    Periodic Task = przerwanie zegara; Event Task = przerwanie np. linii wejścia. W sumie to bez różnicy.

    Przykłady 1-3 można podsumować jednym zdaniem: na przerwaniu/zadaniu cyklicznym wykonujemy coś wydzielonego, co powinno mieć krótki i stały okres powtarzania. Wygodniej jest ustawić stały cykl wykonania dla jednego zadania periodycznego niż dbać o stały (i krótki) cykl całego programu w sterowniku. I to ma sens.

    Ale gdy zadań/przerwań jest więcej, mają różne cykle i niepomijalny czas wykonania, to zaczną sobie deptać po piętach i musi pojawić się jitter dla tych o niższych priorytetach, więc dokładność idzie na spacer.

    Ciekawostka a propos punktu 4: GE PAC Systems RX7i z redundancją nie pozwala uruchamiać kodu na przerwaniach zegara (ani żadnych innych). Bez redundancji mamy ich pełny wybór.
  • #13
    adamac2
    Automation specialist
    Quote:
    Periodic Task = przerwanie zegara; Event Task = przerwanie np. linii wejścia. W sumie to bez różnicy.


    Jest różnica bo widziałem już programy wywoływane co 2 ms żeby sprawdzać jedno wejście i wykonać program, gdzie można było wywołać podprogram od tego wejścia i wykonać program (pierwsza opcja to zarzynanie CPU).

    Quote:
    Ciekawostka a propos punktu 4: GE PAC Systems RX7i z redundancją nie pozwala uruchamiać kodu na przerwaniach zegara (ani żadnych innych). Bez redundancji mamy ich pełny wybór.


    Nazwałbym to cechą. Bo nie widzę ani w tym nic pozytywnego ani nic negatywnego. Widziałem już redundancje na periodic task i żadnych problemów nie odnotowano. Napewno periodic task pozwala ogarnąć czasami podbramkowe sytuację:).
  • #14
    jestam
    Automation specialist
    adamac2 wrote:
    Jest różnica bo widziałem już programy wywoływane co 2 ms

    Bez różnicy w sensie konsekwencji dla programisty - w obu przypadkach wprowadzamy asynchroniczne wykonanie kodu, mniejsza z tym co go wywołuje. W wydajności oczywiście jest różnica. W sumie przerwania w procesorach wprowadzono po to, żeby nie marnować czasu na pooling.

    adamac2 wrote:
    Bo nie widzę ani w tym nic pozytywnego ani nic negatywnego

    Osobiście bym wolał, żeby redundacja GE radziła sobie z przerwaniami, choćby tylko tymi od zegara... :) Dla mnie brak tej funkcji jest negatywny.

    adamac2 wrote:
    Napewno periodic task pozwala ogarnąć czasami podbramkowe sytuację

    Prawda :) Fajnie mieć w zanadrzu coś takiego.
  • #15
    Rariusz
    Automation specialist
    Witam,

    jestam wrote:

    Nie znam Rockwella na tyle dobrze, żeby się tutaj autorytatywnie wypowiadać. Potraktuj wszystko co poniżej z pewną dozą ostrożności :)


    Ja też nie, to dopiero Mój pierwszy projekt. Gdyby nie ten temat nie zwróciłbym uwagi na powyższe problemy.
    Dziękuję za dokumentacje w wolnej chwili dokładnie przeczytam. Zwróciłem uwagę na przykładowy
    przebieg programu w momencie występowania przerwań. Zastanawia mnie właśnie fakt jaki został poruszony
    odnośnie dzielenia zasobów. Stosując przerwanie (będę to określenie stosował dalej jako określenie zadań oraz przerwań)
    przy stosowaniu regulatora PID warto zwrócić uwagę że wartość wyjściowa z regulatora, która trafia na wyjście przykładowo
    analogowe. Tu mogę się pojawić problemy bo często wartość jest skalowana i w trakcie skalowania może
    nastąpić przerwanie i wartość ulegnie zmianie. W niektórych procesach jak już pisałem może to być bez
    znaczenie a w niektórych tak. Warto przenieść wszystko do jednego bloku.


    jestam wrote:
    Nie widzę ani słowa na ten temat. Nie widzę także żadnych bloków do synchronizacji (typu semafory). Norma nie wymaga, producent PLC ma wolną rękę. Nawet gdyby semafory były dostępne, to pojawia się jeszcze problem inwersji priorytetów. Nic na ten temat nie widzę.


    Też przyszły mi na myśl semafory oraz ich implementacja. Jednak te sprawę omówię z moim znajomym,
    który zajmuje się programowaniem współbieżnym i omówię z nim ten problem. Człowiek zna się na rzeczy
    i może coś powstanie z tego ciekawego.

    jestam wrote:
    Takie błędy są praktycznie nieznajdowane, nawet jeśli wiadomo że są w programie.


    Co w przypadku gdy proces jest szybko zmienny ? (wiem że cięgle o tym pisze ale nie można tego pominąć)
    Myślę czy jest sens implementacji semafora i przeprowadzenia testów żeby sprawdzić jak to ma się
    w rzeczywistości.

    adamac2 wrote:
    Nie wiem dlaczego rozdzieliłeś wyliczanie SP oraz wywoływanie PID'a (dla mnie to raczej są to zadania ściśle powiązane Smile)

    jestam wrote:
    Programy przykładowe rzadko są dobrymi wzorami.


    Źle napisałem. Mam stary program z maszyny i przerabiam dla nowej praktycznie identycznej.
    Obsługa ramp jest wykonywana co 10ms, PID co 200ms (nie jestem pewny na 100%).
    Do tego dochodzi odczyt wartości zadanej w MAIN oraz skalowanie i zapis do wyjść analogowych
    również w MAIN. Regulatory kontrolują temperaturę w piecu.

    jestam wrote:
    Masz na myśli "programowanie sterowane zdarzeniami"?

    Miałem na myśli przerwania a nie zdarzenia. Przepraszam za wprowadzenie w błąd.

    jestam wrote:

    Mało tego, "współbieżne" diagramy sekwencji (SFC, Graph i podobne) mogą być (i zwykle są) wykonywane bez wielozadaniowości.


    Są stosowane do opisu procesów współbieżnych, które nie muszą być wykonywane przez kilka
    procesorów, ma na myśli linie gdzie poszczególne elementy montowane są równolegle lub jakiś
    proces posiada elementy, które są wykonywane jednocześnie. Proszę nie mylić z programowaniem
    ściśle współbieżnym. Po prostu zastosowanie sieci Petriego i przeniesienie tego na SFC pozwala
    na znaczące uproszczenie programu. W przypadku zwykłego automatu stanu, wynik jaki uzyskamy
    na końcu może okazać nie do przyjęcia (duża ilość stanów itd).


    jestam wrote:
    np. takie, że zawsze X+Y = 10 (czyli zawsze jest wykonane X := cośtam, Y := 10 - X), ups... Zrób bufor kołowy bez zależności między głową i ogonem Smile


    Czy możesz rozwinąć to co napisałeś? odnośnie tego bufora.

    jestam wrote:
    Rozkazy fizycznego procesora są (w uproszczeniu) nieprzerywalne. I = 10 może być zrealizowane jako (Ładuj 10 do komórki pamięci I) - zapewne nieprzerywalne, ale może być też (Ładuj 10 na stos/do akumulatora; Zapisz szczyt stosu/akumulator do komórki pamięci I) - jak najbardziej przerywalne.


    Dziękuję za wyjaśnienie.


    adamac2 wrote:
    Ale na dwóch podprogramach to raczej nie zarżniemy CompactLogixa

    adamac2 wrote:
    Te przerwania w twoim rozumieniu to podprogramy Periodic


    Dokładnie mam ich 5. MAIN + 4 Periodic Task.


    jestam wrote:
    Ciekawostka a propos punktu 4: GE PAC Systems RX7i z redundancją nie pozwala uruchamiać kodu na przerwaniach zegara (ani żadnych innych). Bez redundancji mamy ich pełny wybór.


    Oraz niektórych modułów specjalnych np. do pozycjonowania. Programowałem tego typu system na sterownikach RX3i
    i to już trzeba obejść się bez przerwań itp. Inne podejście do programowania.


    adamac2 wrote:
    Napewno periodic task pozwala ogarnąć czasami podbramkowe sytuację

    Jeżeli zastosujemy PLC np. RX3i i mam funkcję napisaną w C która ma wejścia oraz wyjść to
    periodic task już nie zastosujemy.


    Zachęcam do dalszej dyskusji.

    Pozdrawiam,
  • #16
    adamac2
    Automation specialist
    Quote:
    u mogę się pojawić problemy bo często wartość jest skalowana i w trakcie skalowania może
    nastąpić przerwanie i wartość ulegnie zmianie. W niektórych procesach jak już pisałem może to być bez
    znaczenie a w niektórych tak. Warto przenieść wszystko do jednego bloku.


    Wejścia / wyjścia używane n.p: przez pid w periodic task powinny być mapowane / skalowane w tym samym periodic task. Tak chyba nawet dokumenty AB głoszą.

    Quote:
    okładnie mam ich 5. MAIN + 4 Periodic Task.


    Też da radę:). Chodź te 10 ms dla ramp. to chyba trochę przesada A stary program maszyny w jakim PLC-ku siedział?
  • #17
    jestam
    Automation specialist
    adamac2 wrote:
    Wejścia / wyjścia używane n.p: przez pid w periodic task powinny być mapowane / skalowane w tym samym periodic task

    Koniecznie! Jaki sens wykonać PIDa na nieaktualnych stanach wejść (czytanych w innym momencie czasu)?

    Rariusz wrote:
    Też przyszły mi na myśl semafory oraz ich implementacja

    Jeśli mowa o zwykłych przerwaniach, to zapomnij. Tylko synchronizacja nieblokująca. Niech przerwanie A o niższym priorytecie zajmie semafor, zostanie wywłaszczone przez przerwanie B, które chce zająć ten sam semafor. B musi czekać, ale jak długo B czeka, tak długo A jest wywłaszczone. Zakleszczenie.
    Koncepcja zadań z normy IEC nie zabraniają semaforów wprost, ale też norma ich nie wymaga. Producent sterownika musiałby to przewodzieć i obsłużyć.

    Rariusz wrote:
    Obsługa ramp jest wykonywana co 10ms, PID co 200ms (nie jestem pewny na 100%). Do tego dochodzi odczyt wartości zadanej w MAIN oraz skalowanie i zapis do wyjść analogowych również w MAIN.

    Po co zmieniać SP co 10 ms, skoro PID odczyta zmieniony SP co 200 ms? 19 zmian przejdzie niezauważonych.
    Wszystkie wymienione operacje (odczyt we, skalowanie, rampy, wszystkie PIDy po kolei, skalowanie, zapis wy) wykonałbym w jednym zadaniu. Jeśli chcesz rampy co 10ms, a PID co 200 ms, to PID co 20 wykonań zadania. MAIN zostaje pusty.

    Rariusz wrote:
    Czy możesz rozwinąć to co napisałeś? odnośnie tego bufora.

    Klasyka: czytelnicy i pisarze. Zaimplementuj tak, żeby bufor działał przy dostępie z różnych zadań.

    Rariusz wrote:
    Jeżeli zastosujemy PLC np. RX3i i mam funkcję napisaną w C

    Programowanie sterowników w C to jest kolejny temat z rodzaju "dwóch nienaruszalnych zasad" :)

    Przykład: kiedyś dawno temu, GE udostępniło mastera Modbus napisanego w C dla RX7i. Blok miał parametr "nr portu" o 2 możliwych wartościach. I fajnie, tylko blok w C nie jest blokiem funkcyjnym i nie może mieć instancji! Więc GE udostępniło 2 wersje, dla różnych portów szeregowych...
  • #18
    Rariusz
    Automation specialist
    Witam,

    adamac2 wrote:
    Wejścia / wyjścia używane n.p: przez pid w periodic task powinny być mapowane / skalowane w tym samym periodic task. Tak chyba nawet dokumenty AB głoszą.


    Ja nie mam tak zrobione ale już tak zostawię. Na przyszłość będę pamiętał
    choć i tak, jak bym robił to wszystko znalazłoby się w jednym bloku.

    adamac2 wrote:
    Chodź te 10 ms dla ramp. to chyba trochę przesada


    Dokładnie wygląda to tak:
    1) Main - Continuous, Watchdog 500ms
    2) Rampa - Periodic 10ms, Watchdog 2000ms, Priority 1
    3) PID - Periodic 100ms, Watchdog 500ms, Priority 4
    4) BLOK_X1 - Periodic 60000ms, Watchdog 500ms, Priority 10
    5) BLOK_X2 - Periodic 500ms, Watchdog 500ms, Priority 2

    Proszę o uwagi co do tych ustawień jeśli ktoś uzna że są
    nieprawidłowe.
    Wcześniej był Controllogix. Program uległ znacznemu zmniejszeniu oraz
    maszyna zawiera dwa sterownik. Drugi sterownik obsługuję jedną z
    części maszyny. Drugi całą resztę.


    jestam wrote:
    Programowanie sterowników w C to jest kolejny temat z rodzaju "dwóch nienaruszalnych zasad"


    Ja nie widzę nic złego w pisaniu funkcji w C dla PLC GE. Proszę zauważyć
    że rozproszony moduł wejść/wyjść ENIU wykorzystywany przykładowo
    w systemie redundantnym GE zawiera funkcję RCCM "C"
    ( COMMREQ) do obsługi komunikacji:
    - Genius Bus Controller
    - Profibus Master
    - DeviceNet Master
    - Motion Module (DSM314)
    - Motion Module (DSM324)
    - High Speed Counter
    - Modbus Master
    - Hart
    - ENIU (Read last COMMREQ)

    Funkcja wywoływana jest w module ENIU do wymiany danych pomiędzy urządzeniami
    z którymi moduł się komunikuje a wyminą danych EGD z PLC.

    Ostatnio implementowałem proste sterowanie MPC. Problem pojawił się
    w trakcie potrzeby przechowywania danych z poprzedniego wywołania
    bloku ale to załatwiłem zmiennymi statycznymi.


    jestam wrote:
    Jeśli mowa o zwykłych przerwaniach, to zapomnij. Tylko synchronizacja nieblokująca. Niech przerwanie A o niższym priorytecie zajmie semafor, zostanie wywłaszczone przez przerwanie B, które chce zająć ten sam semafor. B musi czekać, ale jak długo B czeka, tak długo A jest wywłaszczone. Zakleszczenie.


    Fakt, o tym zapominałem. muszę jeszcze trochę poczytać na temat programowania współbieżnego bo brakuję mi wiedzy na ten temat.

    jestam wrote:
    mastera Modbus napisanego w C dla RX7i

    Dziwna sprawa. Ja to robiłem z wykorzystaniem funkcji COMMREQ.


    Pozdrawiam,
  • #19
    jestam
    Automation specialist
    Rariusz wrote:
    Proszę o uwagi co do tych ustawień

    Wyliczanie rampy częściej niż PID z niej korzysta nie ma sensu. Nie piszesz jaki jest czas wykonania tych zadań, ale pewnie max pojedyncze milisekundy. Bardzo długie czasy watchdog.

    Ja bym zrobił CTRL+C CTRL+V i wkleił cały kod do jednego periodycznego zadania z cyklem 100 ms. Ewentualnie ustawił wszystkim cykl 100 ms i priorytety tak, aby np. rampa wykonywała się przed PIDem czyli rampa wyższy priorytet niż PID.

    Abstrahując od tego przypadku, dobrze jest stosować regułę Rate Monotonic: im krótszy okres tym wyższy priorytet. Czyli u Ciebie kolejność priorytów zad. 2, 3, 5, 4. Wtedy można użyć prostej zasady: jeśli obciążenie CPU < 69% to wszystkie zadania zdążą się wykonać.

    Edit: dodane, bo kliknąłem Wyślij zamiast Podgląd.

    Rariusz wrote:
    Ja nie widzę nic złego w pisaniu funkcji w C dla PLC GE

    Wolę ST, który się pojawił w pewnym momencie w PAC RX.
    Problem jest w
    Rariusz wrote:
    przechowywania danych z poprzedniego wywołania
    bloku ale to załatwiłem zmiennymi statycznymi.

    W C nie zrobisz łatwo bloku funkcyjnego. Jak dla mnie, jest to kolejne z narzędzi ostatniej szansy. Fajnie że jest, ale...
    Rariusz wrote:
    zawiera funkcję RCCM "C" ( COMMREQ) do obsługi komunikacji

    Trochę się zgubiłem. Jaki związek ma COMMREQ z blokami w C? Który moduł ENIU masz na myśli?

    <disclaimer>Jestem trochę do tyłu z technologią GE</disclaimer>

    Rariusz wrote:
    Dziwna sprawa. Ja to robiłem z wykorzystaniem funkcji COMMREQ

    To było dawno temu, zanim GE dodał obsługę Modbus do firmware. Poszło na PW. Tam jest napisane "The folders and “C” blocks associated with this application bulletin are subject to US export control.", więc nie wysyłaj do Iranu :)
  • #20
    Rariusz
    Automation specialist
    Witam,

    jestam wrote:
    Nie piszesz jaki jest czas wykonania tych zadań, ale pewnie max pojedyncze milisekundy.

    Tego jak narazie nie mogę sprawdzić ale w przyszłym tygodniu będę uruchamiał
    maszynę więc zwrócę uwagę.
    jestam wrote:
    Wyliczanie rampy częściej niż PID z niej korzysta nie ma sensu.

    Dla mnie też. Zostawię jak jest i na uruchomieniu zobaczę jak sterownik będzie
    pracował. Dodatkowo skonsultuję się z serwisantem.
    jestam wrote:
    Wolę ST, który się pojawił w pewnym momencie w PAC RX

    Wygodniejszy i duże możliwości. Standard w PLC. Nie wszyscy producenci
    wspierają C. Ciekawi mnie fakt jakie rozwiązania stosują np. B&R oraz Beckhoff
    w swoich sterownikach które mają np. dwa rdzenie?. Tu już należałoby się
    zapoznać z platformą oraz porozumieć ewentualnie z producentem.
    jestam wrote:
    Jaki związek ma COMMREQ z blokami w C? Który moduł ENIU masz na myśli

    Odsyłam do PACSystems RX3i Ethernet NIU User’s Manual, GFK-2439. Rozdział 8 oraz 9.

    Pozdrawiam
  • #21
    jestam
    Automation specialist
    Rariusz wrote:
    Ciekawi mnie fakt jakie rozwiązania stosują np. B&R oraz Beckhoff
    w swoich sterownikach które mają np. dwa rdzenie?.


    Beckhoffa programuje się zgodnie z normą IEC. Jest środowisko runtime uruchamiane na Windows CE lub XP. Są wspierane zadania, ale jak one się przekładają na procesy/wątki systemu operacyjnego, tego nie wiadomo. Liczba rdzeni procesora nie jest nigdzie widoczna dla programisty PLC, czy runtime umie wykorzystać wiele rdzeni - nie wiadomo.

    Rariusz wrote:
    GFK-2439. Rozdział 8 oraz 9

    Dzięki. Niestety moje kontakty z RX3i były dość ograniczone.
    Mam wrażenie, że w tym dokumencie GE używa słowa COMMREQ w innym znaczeniu niż np. w GFK-2220. Muszę to dokładniej przeanalizować.

    Dla mnie COMMREQ to bloczek dostępny w języku LD w sterownikach GE, którego pierwszy parametr wskazuje na adres w pamięci (np. %R) zawierający strukturę opisującą, co właściwie ten bloczek ma zrobić. W ten sposób jeden bloczek załatwia wszystkie protokoły komunikacyjne :)
  • #22
    Rariusz
    Automation specialist
    Witam,

    jestam wrote:
    Mam wrażenie, że w tym dokumencie GE używa słowa COMMREQ w innym znaczeniu niż np. w GFK-2220.


    Blok wykorzystywany jest do komunikacji i jest przeznaczony dla modułu ENIU.
    Nazwa jest nawet inna. Nie miałem okazji korzystać z tej funkcji
    ale przy najbliższej okazji przetestuję działanie.

    Trochę odbiegamy od tematu :D

    Pozdrawiam,