logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Mitsubishi MR-J4-TM - tryb pracy i komunikacja Profinet z PLC Siemens

Henry(k) 23 Paź 2018 22:44 1875 3
  • #1 17514123
    Henry(k)
    Poziom 30  
    Witam.

    Wybaczcie jeśli coś oczywistego, ale pierwszy raz w rękach mam.
    Jest falownik Mitsubishi MR-J4-TM oraz S7-1200 z którego będę go sterować (TiA Portal 15).
    Chcę pojechać na zadany punkt a potem wrócić do bazowego (przekładnia silnik na przesuw liniowy). Z dostępnych 4 trybów rozumiem więc że najlepiej pasuje Telegram 102, bo mam kontrolę nad pozycją dojazdu, prędkością z jaką to robi i siłą aby w razie czegoś po drodze zatrzymał się. No i chyba teoretycznie prostsze składanie komend zamiast po kolei w paczkach po jednej w jedną i drugą.

    Drugi temat, to... jak właściwie z tym się wymienia danymi?
    Mam te 48 bitów w I/O tags. Ustawiam sobie parametry, pozycję docelową, w COntrolword daję enable operation i jedzie?
    Ale jest jeszcze coś takiego jak "module parameters" a w nim 24 PNU IN i 24 PNU OUT wypełnionych już parametrami które mogę to zmienić. Definiuję tu na sztywno pewne parametry?, to, co nie chcę defaultowego?

    Nie mogę namierzyć w sieci jakiegoś przykładu stąd pytania :cry:

    Pozdrawiam.
  • #2 17520886
    Telex
    Poziom 28  
    Witam,

    Z przykładami jest ciężko. Osobiście np. z Rexroth i Siemens to sam w dokumentacji (napędów, sterowników i innych), szukam opisu odpowiednich ramek PZD i następnie sam tworzę UDT i na szybko DB do wymiany danych. Trochę to upierdliwe ale jak raz sobie stworzysz typy danych UDT to już masz z górki. Osobiście mogę pomóc z HCS Rexroth'a i i V90 Siemensa. Obecnie na warsztacie G120C i ABB AC355.

    A co do wymiany danych to trzeba skorzystać z SFB14 DPRD_DAT - czytanie, oraz SFB15 DPWR_DAT - wysyłanie. Bloki te obsługują zarówno i DP jak i PN.
  • Pomocny post
    #3 17524487
    Jarik
    Specjalista Automatyk
    Bloki SFB14/15 wykorzystujesz do cyklicznej wymiany danych z serwo-napędami. SFC14 odczytujesz strukturę danych statusu serwa a SFC15 Zapisujesz cała strukturę. Potrzeba po 48 bajtów do sterowania i odczytu stanu serwa. Telegram 102 jak najbardziej odpowiedni dla twojego zastosowania. Umożliwia sterownie wszystkimi trybami serwa PP, PV, TQ i HOMING w tym zmianę trybów pracy, czyli najpierw bazujesz potem sterujesz w dowolnym trybie pracy.
    Niestety jest jeden problem, istnieje możliwość pracy tylko w jednym trybie. Nie ma możliwości składania trybów pracy. Przy TQ serwo pojedzie do czasu osiągnięcia zadanego momentu nie jest istotna pozycja napędu. I odwrotnie w trybie PP po przekroczeniu momentu serwo zatrzyma się z alarmem. Moment alarmu w trybie PP z tego co pamiętam nie jest tym z bloku danych wysyłanych synchronicznie tylko tych z parametrów napędu.
    Jeżeli chodzi o przesyłanie (komunikacja asynchroniczna) parametrów to do tego potrzebujesz SFB53 do zadania zapytania o parametry i SFB52 do odczytania parametrów. Tego samego zestawu potrzebujesz też do zapisu parametrów. Najpierw zapisujesz potem potwierdzasz zapis.
    Trzeba pamiętać o jednej rzeczy że niektóre parametry potrzebują cyklu wyłącz/włącz zasilanie do zapamiętania ich w serwonapędzie.
    Ja implementowałem te serwa jakieś 3 lata temu na S7-315 2PN. Na S7-1200 robi się tak samo czyli te same bloki są dostępne w TIA, DPRD_DAT/DPWR_DAT do komunikacji synchronicznej i acyklicznej RDREC/WRREC.
  • #4 17524653
    Henry(k)
    Poziom 30  
    Dziękuję za cenne wskazówki.
    Trybów przełączać nie będę potrzebował, mam dojechać na punkt a tylko wykryć przeciążenie przy ustalonym progu = alarm.

    Jeszcze tylko rozgryźć jak działają te "module parameters" i dlaczego domyślnie są wpisywane takie, jakie są.
    Mam już i silnik więc będę testował.

    Dziękuję i Pozdrawiam.
REKLAMA