Propojení GX Simulatoru s Factory I/O prostřednictvím OPC

Virtuální uvedení do provozu je užitečné tehdy, když se simulovaná scéna chová jako řízený stroj, nikoli jako odpojená animace. U projektu PLC Mitsubishi to vyžaduje sledovatelnou datovou cestu ze simulátoru GX pro vývojové prostředí přes kompatibilní OPC server až k tagům Factory I/O.

Cílem není pouze uvést dopravník do pohybu. Užitečné nastavení ověří vlastnictví adres, směr signálů, chování sekvence, blokovací podmínky, časování, reakci na ztrátu komunikace a logiku restartu ještě předtím, než budou k dispozici fyzické I/O.

Malý virtuální dopravník může odhalit chyby mapování, časování a obnovy ještě předtím, než se projeví ve skutečném rozvaděči.

Před mapováním tagů ověřte kompatibilitu softwaru

„GX Simulator“ může označovat simulační funkce spojené s různými generacemi GX Works a rodinami CPU MELSEC. Produkty OPC se také liší verzí a tím, zda poskytují OPC DA nebo OPC UA. Ovladače ve Factory I/O nemusí všechny kombinace podporovat stejným způsobem.

Zapište si přesnou rodinu PLC, verzi GX Works, simulační komponentu, produkt a verzi OPC serveru, typ rozhraní a verzi Factory I/O. Poté ověřte, že se OPC server dokáže připojit k danému simulovanému CPU. Nepředpokládejte, že způsob připojení fungující s fyzickým ethernetovým modulem bude automaticky fungovat i se softwarovým simulátorem.

Společnost Mitsubishi popisuje MX OPC jako software, který zpřístupňuje data programovatelných automatů MELSEC prostřednictvím OPC. Novější hardware MELSEC iQ-R může také používat integrovaný server OPC UA, tato architektura se však liší od serveru provozovaného na počítači a připojeného k simulovanému řídicímu systému. Tyto cesty v projektové dokumentaci a při řešení problémů rozlišujte.

Datový kontrakt vytvořte před konfigurací softwaru

Vytvořte seznam I/O s jedním řádkem pro každý signál. Uveďte tag Factory I/O, adresu zařízení Mitsubishi, datový typ, směr, význam v rámci technologie, výchozí stav, bezpečný stav, požadavek na aktualizaci a vlastníka. Simulace by měla běžně vlastnit stavy vstupů z technologie, zatímco logika PLC by měla vlastnit příkazy akčních členů.

Toto pravidlo vlastnictví brání tomu, aby stejný bod zapisovaly dvě aplikace. Simulovaný fotoelektrický snímač může zapisovat vstupní zařízení PLC, zatímco PLC zapisuje příkaz motoru, který čte Factory I/O. Pokud obě strany zapisují do jednoho tagu, zobrazení může blikat nebo působit náhodně, přestože je každé jednotlivé připojení technicky aktivní.

Bitová zařízení, slova, znaménková celá čísla, čísla s plovoucí desetinnou čárkou a pole vyžadují jednoznačné zpracování typů. OPC klient může hodnotu úspěšně zobrazit, zatímco Factory I/O ji interpretuje s nesprávným typem nebo pořadím bitů. Začněte jedním booleovským bodem a jedním slovem, jejichž měnící se hodnoty jsou nezaměnitelné. Rozšiřujte konfiguraci až po ověření směru a škálování.

Připojení sestavujte a testujte po vrstvách

Nejprve vytvořte minimální program PLC a spusťte jej v podporovaném simulátoru GX. Vynuťte nebo přepněte známé interní zařízení a ověřte, že monitor žebříkového diagramu zobrazuje očekávaný stav. Tím potvrdíte správnou funkci programu, vybraného CPU a simulátoru.

Poté nakonfigurujte OPC server pro daný simulovaný řídicí systém. Vytvořte pouze několik testovacích tagů. Pomocí vlastního klienta serveru nebo diagnostického zobrazení ověřte kvalitu, časové razítko, hodnotu a možnost zápisu. Hodnotu označenou jako „bad“ nebo „uncertain“ je třeba opravit na této vrstvě ještě před spuštěním Factory I/O.

Ve třetím kroku nakonfigurujte OPC klienta ve Factory I/O a vyhledejte nebo zadejte ověřené tagy. Namapujte jeden simulovaný snímač a jeden příkaz akčního členu. Oba směry ověřte samostatně: změňte vstup scény a sledujte paměť PLC, poté změňte výstup PLC a sledujte scénu.

Tento vrstvený postup odděluje jednotlivé závady. Pokud se paměť GX nemění, problém je v simulaci PLC. Pokud se GX mění, ale OPC klient nikoli, zkontrolujte konfiguraci serveru a adresování zařízení. Pokud je OPC server v pořádku, ale Factory I/O zůstává beze změny, prověřte připojení klienta, názvy položek, přístupová práva a mapování tagů.

Ověřování po vrstvách izoluje závady konfigurace PLC, OPC serveru a Factory I/O.

Zohledněte časování mezi třemi nezávislými systémy

Sken PLC, dotazování OPC serveru, odběr klienta a aktualizace fyziky ve Factory I/O neprobíhají ve stejném okamžiku. Impulz snímače kratší než souhrnný interval vzorkování může zmizet dříve, než jej PLC zaznamená. Zatížení sítě nebo počítače může i na místní pracovní stanici způsobit kolísání.

Důležité události musí být navrženy tak, aby přežily vzorkování. Simulované zařízení může držet stav až do potvrzení, případně může logika PLC zachytit změnu a držet ji, dokud ji sekvence nezpracuje. Prodlužování každého impulzu je sice vhodné pro demonstraci, ale může skrýt chyby při zpracování hran. Testovací chování přizpůsobte očekávanému fyzickému snímači a výrobní rychlosti.

Pokud je časování sekvence důležité, měřte skutečné zpoždění od konce ke konci a nepředpokládejte, že nastavená rychlost aktualizace OPC představuje úplnou latenci. Zaznamenejte přechod scény, časové razítko OPC, okamžik pozorování v PLC, rozhodnutí o výstupu a následnou akci ve scéně.

Počítejte s omezeními OPC DA a pracovní stanice

Klasické OPC DA používá technologii Microsoft COM. Pokud všechny aplikace běží pod jedním účtem Windows na jednom počítači, bývá nastavení jednodušší. Distribuované konfigurace přinášejí problémy s identitou DCOM, oprávněními, firewallem a servisními účty. Připojení, které funguje při interaktivním spuštění, může po restartu selhat, pokud se OPC server spustí pod jiným účtem.

OPC UA používá odlišný bezpečnostní model s koncovými body, certifikáty a zásadami. Odstraňuje závislost na DCOM, stále však vyžaduje důvěryhodné certifikáty, uživatelská oprávnění a kompatibilní datové modely. Použijte rozhraní skutečně podporované vybraným softwarem a nepovažujte DA a UA za vzájemně zaměnitelné názvy.

Selhání a stavy po restartu testujte záměrně

Odpojte OPC klienta, když je dopravník aktivní. Zastavte simulátor PLC. Restartujte OPC server. Znovu otevřete Factory I/O s dříve zapnutými výstupy. Stroj nesmí obnovit nebezpečný pohyb pouze proto, že se znovu objeví zastaralé hodnoty nebo se klient znovu připojí.

Definujte reakci na špatnou kvalitu, ztrátu komunikace a spouštěcí hodnoty. Příkazy lze v závislosti na procesu vynutit do vypnutého stavu, podržet nebo zpracovat řízeným zastavením. Vstupy mohou vyžadovat explicitní bit stavu komunikace, aby PLC dokázalo odlišit skutečný nulový stav od nedostupných dat.

Otestujte také studený start, teplý restart, zachování čítačů, nesoulad receptury, zablokované snímače, současné příjezdy a reset obsluhou. Zdokumentujte počáteční stav každého zapisovatelného tagu a sekvenci potřebnou k přechodu do automatického režimu.

Proměňte virtuální buňku v testovací přípravek

Používejte opakovatelné akceptační případy: žádný akční člen před splněním podmínek spuštění; jeden započítaný kus na každý výrobek; řízené zastavení v cílovém místě; časový limit při zablokovaném snímači; porucha při ztrátě komunikace; a předvídatelné obnovení po opětovném připojení. Trendy tagů a záznamy úspěšných či neúspěšných testů poskytují silnější důkazy než snímky obrazovky pohybující se scény.

Možnosti řídicích systémů Mitsubishi si můžete prohlédnout v kolekci Mitsubishi Electric, širší nabídku hardwaru řídicích systémů najdete v kolekci PLC & PAC Systems.

OPC je pouze přenosová vrstva. Inženýrská hodnota se projeví tehdy, když se virtuální buňka stane opakovatelným testovacím prostředím pro chování PLC, vlastnictví signálů, předpoklady časování, reakci na poruchy a logiku restartu, které se přenesou i do fyzického stroje.