Назад към блога

Свързване на GX Simulator с Factory I/O чрез OPC

Стабилната конфигурация за виртуално въвеждане в експлоатация на Mitsubishi изисква повече от съвпадащи адреси. Изградете и тествайте пътя GX симулатор–OPC–Factory I/O с ясно определена собственост...

Виртуалното въвеждане в експлоатация става ценно, когато симулираната сцена се държи като управлявана машина, а не като несвързана анимация. За проект с Mitsubishi PLC това изисква проследим път на данните от инженерния симулатор GX, през съвместим OPC сървър, до таговете във Factory I/O.

Целта не е просто конвейерът да се задвижи. Полезната конфигурация доказва собствеността върху адресите, посоката на сигналите, поведението на последователността, блокировките, времето, реакцията при загуба на комуникация и логиката за рестартиране, преди физическите I/O да са налични.

Сцена с конвейер във Factory I/O, използвана за тестване на симулирана програма за Mitsubishi PLC

Малкият виртуален конвейер може да разкрие дефекти в картографирането, времето и възстановяването, преди те да достигнат до реалния контролен панел.

Потвърдете софтуерната съвместимост, преди да картографирате таговете

„GX Simulator“ може да обозначава симулационни функции, свързани с различни поколения GX Works и семейства MELSEC CPU. OPC продуктите също се различават според версията и според това дали предоставят OPC DA или OPC UA. Драйверите във Factory I/O може да не поддържат всички комбинации по един и същи начин.

Запишете точното семейство PLC, версията на GX Works, симулационния компонент, продукта и версията на OPC сървъра, типа на интерфейса и версията на Factory I/O. След това проверете дали OPC сървърът може да се свърже с този симулиран CPU. Не приемайте, че метод за свързване, който работи с физически Ethernet модул, автоматично ще работи и със софтуерен симулатор.

Mitsubishi описва MX OPC като софтуер, който предоставя данни от програмируеми контролери MELSEC чрез OPC. По-новият хардуер MELSEC iQ-R може да използва и вграден OPC UA сървърен модул, но тази архитектура се различава от сървър, хостван на компютър и свързан със симулиран контролер. Поддържайте тези пътища отделни в проектната документация и при отстраняване на неизправности.

Опишете договора за данни, преди да конфигурирате софтуера

Създайте I/O списък с по един ред за всеки сигнал. Включете тага във Factory I/O, адреса на устройството Mitsubishi, типа данни, посоката, инженерното значение, състоянието по подразбиране, безопасното състояние, изискването за обновяване и собственика. Обикновено симулацията трябва да управлява състоянията на входовете от полето, а логиката на PLC — командите към изпълнителните механизми.

Това правило за собственост предотвратява записването в една и съща точка от две приложения. Симулиран фотоелектрически датчик може да записва входно устройство на PLC, докато PLC записва команда за двигател, която Factory I/O прочита. Ако и двете страни записват един и същ таг, дисплеят може да мига или да изглежда произволен, въпреки че всяка отделна връзка технически е активна.

Битовите устройства, думите, знаковите цели числа, числата с плаваща запетая и масивите изискват изрично управление на типовете. OPC клиентът може успешно да покаже стойност, докато Factory I/O интерпретира неправилно типа или реда на битовете. Започнете с една булева точка и една дума, чиито променящи се стойности са недвусмислени. Разширявайте едва след като посоката и мащабирането са доказани.

Изградете и тествайте връзката на слоеве

Първо създайте минимална програма за PLC и я стартирайте в поддържания GX Simulator. Принудително задайте или превключете известно вътрешно устройство и потвърдете, че мониторът на стълбовидната диаграма показва очакваното състояние. Така се установява, че програмата, избраният CPU и симулаторът работят.

Второ, конфигурирайте OPC сървъра за този симулиран контролер. Създайте само няколко тестови тага. Използвайте собствения клиент или диагностичен изглед на сървъра, за да потвърдите качеството, времевия печат, стойността и възможността за запис. Стойност, маркирана като „лоша“ или „несигурна“, трябва да бъде коригирана на този слой, преди да отворите Factory I/O.

Трето, конфигурирайте OPC клиента във Factory I/O и прегледайте или въведете доказаните тагове. Картографирайте един симулиран сензор и една команда към изпълнителен механизъм. Потвърдете независимо и двете посоки: променете входа в сцената и наблюдавайте паметта на PLC, след което променете изхода на PLC и наблюдавайте сцената.

Този послоен метод разделя неизправностите. Ако паметта на GX не се променя, проблемът е в PLC симулацията. Ако GX се променя, но OPC клиентът не се променя, проверете конфигурацията на сървъра и адресирането на устройствата. Ако OPC сървърът работи нормално, но Factory I/O остава статичен, проверете клиентската връзка, имената на елементите, правата за достъп и картографирането на таговете.

Картографиране на OPC тагове между паметта на устройствата Mitsubishi и сигналите във Factory I/O

Проверката слой по слой изолира неизправностите в конфигурацията на PLC, OPC сървъра и Factory I/O.

Съобразете времето в трите независими системи

Цикълът на PLC, запитването от OPC сървъра, клиентската абонаментна връзка и обновяването на физичния модел във Factory I/O не се случват в един и същи момент. Импулс от сензор, по-кратък от общия интервал на семплиране, може да изчезне, преди PLC да го отчете. Натоварването на мрежата или компютъра може да добави и нестабилност, дори на локална работна станция.

Важните събития трябва да бъдат проектирани така, че да преживяват семплирането. Симулираното устройство може да задържа състоянието си до потвърждение, или логиката на PLC може да запомня открития преход, докато последователността го обработи. Удължаването на всеки импулс е удобно за демонстрация, но може да скрие дефекти при обработката на фронтове. Съобразете тестовото поведение с очаквания физически сензор и производствената скорост.

Измервайте ефективното забавяне от край до край, вместо да приемате, че конфигурираната честота на обновяване на OPC е цялата латентност. Когато времето е важно за последователността, регистрирайте прехода в сцената, времевия печат на OPC, наблюдението от PLC, решението за изхода и последвалото действие в сцената.

Предвидете ограниченията на OPC DA и работната станция

Класическият OPC DA използва технологията COM на Microsoft. Когато всички приложения работят под един акаунт в Windows на един компютър, настройката обикновено е по-лесна. Разпределените конфигурации въвеждат проблеми с идентичността на DCOM, разрешенията, защитната стена и служебните акаунти. Връзка, която работи интерактивно, може да не работи след рестартиране, ако OPC сървърът се стартира под друг акаунт.

OPC UA използва различен модел за сигурност с крайни точки, сертификати и политики. Той избягва DCOM, но все пак изисква доверие към сертификатите, потребителски разрешения и съвместими модели на данни. Използвайте интерфейса, който действително се поддържа от избрания софтуер, вместо да третирате DA и UA като взаимозаменяеми обозначения.

Тествайте умишлено състоянията при отказ и рестартиране

Изключете OPC клиента, докато конвейерът работи. Спрете PLC симулатора. Рестартирайте OPC сървъра. Отворете отново Factory I/O, когато изходите са били включени. Машината не трябва да възобновява опасно движение само защото остарелите стойности се появяват отново или клиентът се свързва повторно.

Определете реакцията при лошо качество на данните, загуба на комуникация и стойности при стартиране. В зависимост от процеса командите могат принудително да се изключат, да се задържат или да се обработят чрез контролирано спиране. Входовете може да изискват изричен бит за състоянието на комуникацията, за да може PLC да различи истинско нулево състояние от недостъпни данни.

Тествайте също студено стартиране, топъл рестарт, запазване на броячите, несъответствие на рецептата, блокирани сензори, едновременни постъпвания и нулиране от оператора. Документирайте началното състояние на всеки записваем таг и последователността, необходима за преминаване в автоматичен режим.

Превърнете виртуалната клетка в тестова система

Използвайте повторяеми приемни сценарии: без изпълнителен механизъм преди разрешенията за стартиране; едно преброяване за всеки продукт; контролирано спиране при достигане на целта; изтичане на времето при блокиран сензор; повреда при загуба на комуникация; и предвидимо възстановяване след повторно свързване. Трендовете на таговете и записите за преминал/непреминал тест предоставят по-силни доказателства от екранни снимки на движеща се сцена.

Опциите за контролери Mitsubishi можете да разгледате в колекцията Mitsubishi Electric, а по-широк избор от хардуер за контролери ще намерите в PLC и PAC системи.

OPC е само транспортният слой. Инженерната му стойност се проявява, когато виртуалната клетка се превърне в повторяема тестова среда за поведението на PLC, собствеността върху сигналите, допусканията за времето, реакцията при неизправности и логиката за рестартиране, които ще се пренесат към физическата машина.

Оставяне на коментар

Имайте предвид, че коментарите трябва да бъдат одобрени, преди да се публикуват.