Łączenie GX Simulator z Factory I/O za pośrednictwem OPC

Uruchamianie wirtualne staje się wartościowe, gdy symulowana scena zachowuje się jak sterowana maszyna, a nie jak odłączona animacja. W przypadku projektu PLC Mitsubishi wymaga to możliwej do prześledzenia ścieżki danych od symulatora inżynierskiego GX, przez kompatybilny serwer OPC, do tagów Factory I/O.

Celem nie jest samo wprawienie przenośnika w ruch. Dobrze przygotowana konfiguracja pozwala zweryfikować własność adresów, kierunek sygnałów, działanie sekwencji, blokady, czasy, reakcję na utratę komunikacji oraz logikę ponownego uruchamiania, zanim dostępne będą fizyczne wejścia i wyjścia.

Mały wirtualny przenośnik może ujawnić błędy mapowania, synchronizacji i przywracania działania, zanim pojawią się w rzeczywistym panelu sterowania.

Przed mapowaniem tagów potwierdź zgodność oprogramowania

„GX Simulator” może oznaczać funkcje symulacyjne powiązane z różnymi generacjami GX Works i rodzinami jednostek CPU MELSEC. Produkty OPC również różnią się wersją oraz tym, czy udostępniają OPC DA czy OPC UA. Dostępne w Factory I/O sterowniki mogą nie obsługiwać każdej kombinacji w ten sam sposób.

Zapisz dokładną rodzinę PLC, wersję GX Works, komponent symulatora, produkt i wersję serwera OPC, typ interfejsu oraz wersję Factory I/O. Następnie sprawdź, czy serwer OPC może połączyć się z symulowaną jednostką CPU. Nie zakładaj, że metoda połączenia działająca z fizycznym modułem Ethernet będzie automatycznie działać z symulatorem programowym.

Mitsubishi opisuje MX OPC jako oprogramowanie udostępniające dane sterowników programowalnych MELSEC za pośrednictwem OPC. Nowsze urządzenia MELSEC iQ-R mogą również korzystać z wbudowanego modułu serwera OPC UA, ale ta architektura różni się od serwera działającego na komputerze i połączonego z symulowanym sterownikiem. W dokumentacji projektowej i podczas rozwiązywania problemów należy wyraźnie rozdzielać te ścieżki.

Przed skonfigurowaniem oprogramowania określ kontrakt danych

Utwórz listę wejść i wyjść zawierającą jeden wiersz dla każdego sygnału. Uwzględnij tag Factory I/O, adres urządzenia Mitsubishi, typ danych, kierunek, znaczenie inżynierskie, stan domyślny, stan bezpieczny, wymagania dotyczące aktualizacji oraz właściciela. Symulacja powinna zwykle zarządzać stanami wejść obiektowych, a logika PLC — poleceniami dla elementów wykonawczych.

Ta zasada własności zapobiega zapisywaniu tego samego punktu przez dwie aplikacje. Symulowany czujnik fotoelektryczny może zapisywać urządzenie wejściowe PLC, podczas gdy PLC zapisuje polecenie silnika odczytywane przez Factory I/O. Jeśli obie strony zapisują ten sam tag, wskazanie może migotać lub wyglądać losowo, mimo że każde pojedyncze połączenie jest technicznie aktywne.

Urządzenia bitowe, słowa, liczby całkowite ze znakiem, wartości zmiennoprzecinkowe i tablice wymagają jawnej obsługi typów. Klient OPC może poprawnie wyświetlać wartość, podczas gdy Factory I/O interpretuje niewłaściwy typ lub kolejność bitów. Zacznij od jednego punktu logicznego i jednego słowa, których zmieniające się wartości są jednoznaczne. Rozszerzaj konfigurację dopiero po potwierdzeniu kierunku i skalowania.

Twórz i testuj połączenie warstwami

Najpierw utwórz minimalny program PLC i uruchom go w obsługiwanym symulatorze GX. Wymuś lub przełącz znane urządzenie wewnętrzne i sprawdź, czy monitor programu drabinkowego pokazuje oczekiwany stan. Potwierdza to działanie programu, wybranej jednostki CPU i symulatora.

Następnie skonfiguruj serwer OPC dla tego symulowanego sterownika. Utwórz tylko kilka tagów testowych. Użyj własnego klienta serwera lub widoku diagnostycznego, aby potwierdzić jakość, znacznik czasu, wartość i możliwość zapisu. Wartość oznaczona jako „bad” lub „uncertain” należy skorygować na tej warstwie przed uruchomieniem Factory I/O.

W trzecim kroku skonfiguruj klienta OPC w Factory I/O i wyszukaj lub wprowadź sprawdzone tagi. Zmapuj jeden symulowany czujnik i jedno polecenie elementu wykonawczego. Potwierdź niezależnie oba kierunki: zmień wejście sceny i obserwuj pamięć PLC, a następnie zmień wyjście PLC i obserwuj scenę.

Metoda warstwowa oddziela źródła usterek. Jeśli pamięć GX się nie zmienia, problem dotyczy symulacji PLC. Jeśli GX się zmienia, ale klient OPC tego nie pokazuje, sprawdź konfigurację serwera i adresowanie urządzeń. Jeśli serwer OPC działa poprawnie, ale Factory I/O pozostaje statyczne, sprawdź połączenie klienta, nazwy elementów, uprawnienia dostępu i mapowanie tagów.

Weryfikacja warstwa po warstwie pozwala odizolować usterki konfiguracji PLC, serwera OPC i Factory I/O.

Uwzględnij synchronizację między trzema niezależnymi systemami

Cykl PLC, odpytywanie serwera OPC, subskrypcja klienta i aktualizacja fizyki Factory I/O nie odbywają się w tej samej chwili. Impuls czujnika krótszy niż łączny odstęp próbkowania może zniknąć, zanim PLC go zaobserwuje. Obciążenie sieci lub komputera może powodować dodatkowe opóźnienia, nawet na lokalnej stacji roboczej.

Ważne zdarzenia należy projektować tak, aby przetrwały próbkowanie. Symulowane urządzenie może utrzymywać stan do chwili potwierdzenia, a logika PLC może zatrzaskiwać wykryte zbocze do momentu wykorzystania go przez sekwencję. Wydłużanie każdego impulsu jest wygodne podczas demonstracji, ale może ukryć błędy obsługi zboczy. Dopasuj zachowanie testu do oczekiwanego czujnika fizycznego i prędkości produkcji.

Mierz rzeczywiste opóźnienie od końca do końca, zamiast zakładać, że skonfigurowany czas aktualizacji OPC jest całkowitym opóźnieniem. Gdy synchronizacja ma znaczenie dla sekwencji, rejestruj zmianę sceny, znacznik czasu OPC, obserwację PLC, decyzję o wyjściu i wynikające z niej działanie sceny.

Uwzględnij ograniczenia OPC DA i stacji roboczej

Klasyczny OPC DA korzysta z technologii COM firmy Microsoft. Gdy wszystkie aplikacje działają na jednym komputerze i pod jednym kontem Windows, konfiguracja jest zwykle prostsza. Konfiguracje rozproszone wprowadzają problemy związane z tożsamością DCOM, uprawnieniami, zaporą sieciową i kontami usług. Połączenie działające interaktywnie może nie działać po ponownym uruchomieniu, jeśli serwer OPC zostanie uruchomiony na innym koncie.

OPC UA korzysta z innego modelu zabezpieczeń, obejmującego punkty końcowe, certyfikaty i zasady. Eliminuje DCOM, ale nadal wymaga zaufania do certyfikatów, uprawnień użytkowników i zgodnych modeli danych. Korzystaj z interfejsu faktycznie obsługiwanego przez wybrane oprogramowanie, zamiast traktować DA i UA jako wymienne określenia.

Celowo testuj stany awarii i ponownego uruchamiania

Odłącz klienta OPC, gdy przenośnik jest aktywny. Zatrzymaj symulator PLC. Uruchom ponownie serwer OPC. Otwórz ponownie Factory I/O z wyjściami, które wcześniej były włączone. Maszyna nie powinna wznowić niebezpiecznego ruchu wyłącznie dlatego, że pojawiły się stare wartości lub klient ponownie się połączył.

Określ reakcję na złą jakość danych, utratę komunikacji i wartości podczas uruchamiania. W zależności od procesu polecenia można wymusić na wyłączone, utrzymać albo obsłużyć za pomocą kontrolowanego zatrzymania. Wejścia mogą wymagać jawnego bitu stanu komunikacji, aby PLC mogło odróżnić rzeczywisty stan fałszywy od niedostępnych danych.

Przetestuj również zimny start, ciepły restart, zachowanie liczników, niezgodność receptury, zablokowane czujniki, jednoczesne nadejścia oraz reset operatora. Udokumentuj stan początkowy każdego zapisywalnego tagu i sekwencję wymaganą do przejścia w tryb automatyczny.

Przekształć wirtualne stanowisko w środowisko testowe

Stosuj powtarzalne przypadki odbiorowe: brak uruchomienia elementu wykonawczego przed spełnieniem warunków zezwolenia; jedno zliczenie dla każdego produktu; kontrolowane zatrzymanie w punkcie docelowym; przekroczenie czasu przy zablokowanym czujniku; błąd w przypadku utraty komunikacji; oraz przewidywalne przywrócenie działania po ponownym połączeniu. Wykresy tagów i rejestry zaliczeń lub niezaliczeń dostarczają mocniejszych dowodów niż zrzuty ekranu poruszającej się sceny.

Opcje sterowników Mitsubishi można przejrzeć w kolekcji Mitsubishi Electric, a szerszy wybór sprzętu sterowników znajduje się w kolekcji Systemy PLC i PAC.

OPC jest wyłącznie warstwą transportową. Wartość inżynierska pojawia się wtedy, gdy wirtualne stanowisko staje się powtarzalnym środowiskiem testowym dla działania PLC, własności sygnałów, założeń dotyczących synchronizacji, reakcji na usterki oraz logiki ponownego uruchamiania, które zostaną przeniesione do rzeczywistej maszyny.