Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

GeFanuc 90 micro komunikacja przez RS232

10 Wrz 2012 11:55 2577 9
  • Poziom 14  
    Witam, jestem początkujący w PLC więc proszę o wyrozumiałość. Dostałem zadanie do zrobienia, mianowicie stworzyć układ za pomocą sterownika Ge Fanuc 90 Micro, który poprzez port rs232 odczytywał by dane z czytnika kodów kreskowych Banner iVu BCR. Czytnik ma zaimplementowany protokół RS232, natomiast nie wiem w ogóle jak podejść do sprawy komunikacji pomiędzy tymi dwoma urządzeniami. Czy może ktoś co nieco podpowiedzieć na ten temat??
    Ewentualnie może znane Wam są jakieś źródła na temat komunikacji szeregowej w w/w sterownikach?? Temat palący, bo szef wymyślił sobie maszynę a ja jeszcze na tak wysokim poziomie programowania nie jestem...
  • Specjalista Automatyk
    Protokół używany przez czytnik jest w jego dokumentacji.
    W sterowniku konfigurujesz port jako "Serial I/O", po czym implementujesz protokół używając bloczków COMMREQ dokumentacja. Zanim zaczniesz, sprawdź, czy Twój sterownik można skonfigurować dla Serial I/O: w podlinkowanej dokumentacji z 2010 r. jest napisane, że 90 Micro nie obsługują Serial I/O. Może coś się zmieniło w nowszym firmware.
  • Poziom 13  
    Napisz proszę jaki konkretnie to jest model 90 Micro.
    Zgodnie z dokumentacją GFK-1065F (Series 90 Micro PLC User's Manual) jeżeli jest to jednostka 23- lub 28- punktowa można uruchomić tryb "Custom" na drugim porcie szeregowym (strona 5-13, link: http://support.ge-ip.com/support/resources/si...aging/DOCUMENT/0/DO881/en_US/1.0/gfk1065f.pdf ). Wtedy korzystając z bloczków COMM_REQ można uruchomić komunikację w trybie Serial I/O.
    Jakim narzędziem programujesz sterownik?
  • Poziom 14  
    Sterownik programuję poprzez Proficy Machine Edition 7.0. Zaszła zmiana i programowanym sterownikiem będzie VersaMax Micro model IC200UDR064. Właśnie próbuję rozgryźć temat COMMREQ i nie bardzo mi to wychodzi. Dzięki wam za linki, są bardzo przydatne.
  • Poziom 13  
    Wszystkie sterowniki Micro (nie 90 Micro o których była mowa wcześniej) obsługują komunikację w Serial I/O, także można uruchomić komunikację ze skanerem.

    Korzystając z COMM_REQ trzeba pamiętać o kilku rzeczach i nie będzie problemu z uruchomieniem:
    1. Ustawienie portu 1 w tryb "Serial I/O" w konfiguracji CPU (jest zamontowana druga karta komunikacyjna czy jest tylko Port 1?).
    2. Program obsługujący port musi wykonywać się sekwencyjnie - najpierw inicjalizacja portu (Initialize Port Function), potem możliwe jest wywoływanie bloku czytającego i wysyłającego na port lub innych.
    3. Blok COMM_REQ nie może być wywołany ponownie przed zakończeniem poprzedniego wywołania. W szczególności NIE można go wywoływać w każdym cyklu pracy sterownika. Najlepiej zwyczajnie wywoływać go impulsem. Wyjście błędu ("FT") jest ustawiane na jeden skan sterownika, jeżeli nie da się wywołać bloku COMM_REQ - NIE mówi ono o statusie komunikacji. Mówi, że np. podano zły numer portu lub blok parametryzujący ma niepoprawne dane i COMM_REQ w ogóle się nie wykonał.
    4. Jeżeli komunikacja odbywa się przez Port 1 na wejścia COMM_REQ trzeba podać: na "Enable" wykrywanie zbocza narastającego, na "IN" adres bloku danych w którym podane są parametry portu, na "SYSID" wartość "0" (mówi, że port znajduje się w "Main Rack"), na "TASK" wartość "19" (jeżeli korzystamy z Portu 1, dla Portu 2 powinna być wartość "20").

    Co może się przydać:
    -instrukcja do sterowników Nano/Micro: http://support.ge-ip.com/support/index?page=docchannel&id=09237d4900112007ff7cf003061
    -przykładowe rozwiązanie (ostatnie cztery strony ze zbioru zadań opracowanych przez ASTOR): http://platforma.astor.com.pl/swt/file/id/4560/

    Jeżeli dalej będzie z tym problem postaram się wysłać jakieś moje programy. Czekamy na informację o postępach ;)
  • Poziom 14  
    Sterownik będzie miał dodatkowy port com, więc muszę odnaleźć gdzieś opcje konfiguracji go. Nigdy nie programowałem pod kątem komunikacji, toteż mam z tym nie lada problem. Jakich bloków danych użyć do tego celu? Jakie są jeszcze istotne informacje?? Kolego PrzemasKSP, dzięki za istotne podpowiedzi, czy mógłbyś mi jednak na PW podesłać jakiś program wykorzystujący komunikację, żebym mógł sie na czymś wzorować?
  • Poziom 13  
    Jeżeli będzie zainstalowany dodatkowy moduł komunikacyjny należy zdefiniować jaki w konfiguracji sprzętowej PLC: otwierając konfigurację CPU w zakładce "CPU Settings" ostatnia pozycja to "Port 2 Configuration". Strzelam, że będzie to RS232. Wtedy pojawi się zakładka "Port 2 (RS232/USB)" - konfiguracja wszystkich parametrów portu.
    Podeślę coś co sam pisałem, ale "gotowiec" na którym można się wzorować jest dwa posty wyżej w zbiorze zadań.
    Ewentualnie: http://platforma.astor.com.pl/swt/file/id/4555/
    To jest manual rodziny VersaMax (nie VersaMax Micro), ale w 12 rozdziale jest opisana po polsku komunikacja szeregowa.
  • Poziom 14  
    Witam, odświeżam troszeczkę temat. Komunikacja już działa, chociaż muszę powiedzieć, że Gefanuc ma strasznie skomplikowaną komunikacją. Problem leży w tym, że nie wiem skąd mi się biorą dziwne wartości w buforze z odebranymi danymi. Dane są przesyłane jako kod ASCII, lecz z bufora wyciągam wartości do niczego nie podobne. Dane odczytuję za pomocą funkcji odczytu znaków(4403) przesyłanej do CommReq. W jaki sposób powinienem to odczytywać? Jakiego typ danych powinna zawierać zmienna bufora wejściowego? (word, string lub co innego? )
  • Poziom 13  
    W buforze odbioru są tylko dane wysłane przez czytnik.
    Należy zwrócić uwagę, że bufor wejściowy wypełnia się niezależnie od funkcji odczytu znaków. Jeżeli np. czytnik wysyła dane (ileś bajtów) cyklicznie, to jeżeli nie jest wywoływana funkcja odczytu znaków bufor wejściowy będzie stopniowo się zapełniał. Funkcja 4403 powoduje odczyt i usunięcie iluś (zależnie od parametrów) odczytanych bajtów danych z bufora wejściowego.
    Obecność danych w buforze może być wykrywana, poza tym wiadomo iloma bajtami czytnik odpowie na żądanie przesłania danych.
    Czy liczba bajtów odczytanych funkcją odczytu znaków zgadza się z tym, co powinien wysłać czytnik?

    Co do typu zmiennej - zależy jak będziemy je analizować. W tym przypadku będą to liczby całkowite, więc wybrałbym WORD lub INT. Być może będzie potrzebna konwersja z ASCII na INT-a, ale tu GE daje gotowce.
  • Poziom 14  
    Odświeżam temat raz jeszcze. Wszystko już działa lecz sterownik wysyła do skanera o jeden znak za dużo. Skaner działa na określoną komendę, która wyzwala skanowanie. Jeżeli komenda ta ma jeden znak za mało lub za dużo to nie jest interpretowana przez skaner i wywala błąd. W moim programie wysyłam do skanera dwie komendy: Pierwsza to "Do Trigger\x0d\x0A", która wywołuje skanowanie, a druga to "Get BCR_Data Result\x0D\x0A", która wywołuje wysłanie odczytanego kodu do sterownika. Pierwsza komenda ma 12 znaków a druga 22. Problem w tym, że gdy wysyłam "Do Trigger\x0d\x0a" to pomimo wszystko wysyła mi jako znak 13 literę "L", która jest tak jakby pozostałością po poprzedniej komendzie "Get BCR..." gdzie litera "L" jest faktycznie 13 w rzędzie. Po ponownym wysłaniu komendy "Do Trigger\x0d\x0a" wszystko jest OK i skanowanie odbywa sie normalnie do momentu wysłania "Get BCR_Result Data\x0A\x0D" i kolejnego "Do Trigger\x0d\x0a".
    "Do Trigger\x0D\x0A" zawiera 12 znaków i tyle też mam zadeklarowane do wysłania w bloku CommReq, więc nie wiem jak tam się znajduje ten 13 znak będący pozostałością po poprzedniej komendzie. Może któryś z kolegów spotkał się już z podobnym problemem i mógłby pomóc.