MetaLab — руководство пользователя

MetaLab подаёт сигналы на входы программы, имитирует датчики и механизмы, читает значения из ПЛК. Сценарий вы составляете в MetaPlatform, а выполняете в Runtime.

Первый сценарий

Начнём с одного тега. Запишем TRUE, прочитаем его, затем запишем FALSE и прочитаем ещё раз. В примере нет двигателя, датчика или другого оборудования.

Скачать проект первого примера

Откройте проект

Импортируйте скачанный проект в MetaPlatform. В MetaGen находится компонент _01_Demo с одним изменяемым тегом Conf.Demo_bSignal. В MetaLab — сценарий FirstSteps.

Откройте таблицу сценария FirstSteps. В ней семь строк:

Что делает каждая строка:

В комментарии чтения первое значение написано автором, второе подставляется из ПЛК. Runner выводит их рядом, но не сравнивает автоматически.

Где объявлен учебный тег

Тег создаётся при генерации из строки Data компонента _01_Demo:

В сгенерированном ST есть оба объявления:

Поэтому в сценарии используется имя Conf.Demo_bSignal. Объявлять этот тег вручную в ST не нужно.

Запустите в Runtime

1. Сохраните проект и выполните генерацию в MetaPlatform. Скачайте артефакты MetaGen и MetaLab.
2. Откройте Runtime. В MetaCore импортируйте артефакт MetaGen. Библиотеки этому проекту не нужны.
3. Задайте период 100 мс, нажмите «Загрузить», затем «Запустить».
4. Откройте MetaLab, импортируйте артефакт MetaLab и нажмите «Загрузить».
5. Нажмите «Из MetaCore», выберите FirstSteps и нажмите «Запустить».

MetaCore выполняет программу с периодом 100 мс. Библиотеки и модели оборудования не подключены.

В журнале видны результаты двух чтений. Сначала прочитано True, затем False.

Одна сессия для нескольких сценариев

Нажатие «Загрузить» в MetaLab открывает сессию и подключение к OPC UA. Инициализация сама не запускается.

Выбирайте следующий сценарий в той же сессии. Созданные модели сохраняются и продолжают работать между запусками. Не загружайте артефакт заново перед каждым сценарием.

«Отменить сценарий» прекращает текущий сценарий, но сохраняет модели и уже выполненные воздействия. «Завершить сессию» останавливает моделирование и удаляет объекты сессии; значения ПЛК автоматически не сбрасываются. После открытия новой сессии снова выполните инициализацию.

Объекты MetaLab

В столбце object укажите объект, к которому обращается строка сценария. В method — его метод. Остальные столбцы содержат параметры этого метода.

Есть три встроенных объекта. Их имена зарезервированы, создавать их не нужно:

Модели пользователь создаёт через factory:

Имена моделей задавайте сами: например PT01, P01, XV01. Обращайтесь к модели по этому имени. Не используйте для неё имена h, opc или factory.

Если у действия указан comment, сценарий после выполнения этого действия ждёт подтверждения пользователя. Исключения: у сообщений h текст выводится как сообщение, у opc.read comment задаёт подпись результата. Ниже это показано для каждого объекта.

Сначала создайте объект, затем настройте его и вызывайте методы. Если объект ещё не создан, сценарий не сможет к нему обратиться.

factory

Создаёт модель. Укажите имя в tag, тип — в value.

Создадим модель датчика PT01:

После этой строки PT01 становится объектом сценария. Например, строка PT01 / const задаёт значение именно этой модели. Повторное создание объекта с тем же именем возвращает уже созданный объект.

h

Выводит сообщения, делает паузы и запрашивает подтверждение оператора.

На строке confirm сценарий остановится и будет ждать «Продолжить». Режим «Автоматически» пропускает подтверждения.

opc

Работает с тегами ПЛК через OPC UA.

write

Записывает значение. В tag укажите имя тега, в value — значение.

Если к действию указан комментарий, сценарий после выполнения действия ждёт подтверждения пользователя для перехода к следующему шагу. В этом примере он запишет TRUE, покажет комментарий и будет ждать «Продолжить». Без комментария перейдёт дальше сразу.

У сообщений h.log текст просто выводится. У чтения opc.read комментарий задаёт формат результата, а не запрос подтверждения.

Для инверсного входа перед именем можно написать NOT:

Строка запишет FALSE в DI_P01_Healthy. Сравнение или составное выражение как адрес записи не подходит.

В какой тег записывать

Сценарий должен писать в тег, который программа не перезаписывает при обновлении View. У входного сигнала может быть отдельное зеркало для отображения:

Пишите в DI_P01_Running, а не в его зеркало. Имя зеркала зависит от проекта: точное имя смотрите в таблице тегов. То же относится к вычисляемым выходам блока — запись в них не заменяет воздействие на вход.

В проекте FirstSteps используется Conf.Demo_bSignal. Программа его циклически не пересчитывает, поэтому он подходит для знакомства с записью и чтением.

read

Читает тег или список тегов. В value укажите 0 для одного чтения. В comment задайте подпись; $1 — первое значение, $2 — второе.

Положительное value задаёт период наблюдения в интерактивном режиме. При автоматическом запуске выполняется одно чтение.

Читайте имена тегов, а не выражения. Для NOT Tag или сравнения используйте отдельный опубликованный результат, если он нужен в проверке.

Неиспользуемые входы

Запись в пустую цель, TRUE, FALSE, NULL или NONE пропускается. Чтение пустой цели, FALSE или NONE возвращает False без ПЛК и помечается в журнале как необъявленный канал. Так базовый сценарий может работать с разными наборами входов.

В списке нескольких тегов пустые элементы и константы недопустимы. Чтение константы не считается проверкой оборудования.

Sensor

Sensor имитирует аналоговый датчик: пишет значение на аналоговый вход программы. Назовём модель PT01, а вход — AI_PT01_Raw.

Подайте постоянное значение

Первая строка создаёт модель. Вторая связывает её с входом. Третья задаёт постоянное значение Raw.

PT01 — имя модели MetaLab. AI_PT01_Raw — тег, который получает значение в программе ПЛК.

Задайте линейное изменение или синусоиду

Перейдём от текущего значения к 20000 за десять секунд:

Теперь включим синусоиду между 6000 и 20000:

Для возврата к постоянному значению вызовите const.

Подайте давление в барах

Чтобы не пересчитывать давление в Raw вручную, задайте шкалы модели. В примере вход модуля — 0–20 мА = Raw 0–27648, датчик — 4–20 мА = 0–10 бар.

На входе получится Raw 16588.8: это 12 мА, или 5 бар. Настройки должны соответствовать обработке датчика в ПЛК — модель не забирает их из Conf автоматически.

Если нужно подать именно ток, используйте const_ev, например 4 мА. const, ramp и sin всегда работают в Raw. Отдельных команд синусоиды в барах или мА нет.

Методы модели датчика

При отключённом масштабировании const_ev и const_fv используют только коррекцию: Raw = (значение − Add) / K. При включённом масштабировании const_fv сначала убирает коррекцию, затем переводит физическую величину в электрическую и в Raw.

Значения за границами шкалы не ограничиваются. Если нужные настройки пропущены или некорректны, например K=0, модель выдаст Raw=0 без отдельного предупреждения. Проверьте шкалы до испытания.

Если входом уже управляет модель, меняйте значение её методами. Одиночную запись opc.write в тот же вход модель может перезаписать.

Engine

Engine имитирует двигатель. Создадим модель P01: она будет читать выход пуска и через секунду выдавать обратную связь «Работа».

Теперь подайте пуск штатным способом управления вашим компонентом. Если программа выдаст DO_P01_Start, модель включит DI_P01_Running.

Проверьте незапуск

Перед этой проверкой остановите двигатель. Контроль состояния в ПЛК должен быть включён. Его нормальная задержка должна учитывать время разгона модели. После проверки верните start_normal.

Методы модели двигателя

Local/remote — положение аппаратного переключателя. Ручной/автоматический режим алгоритма через HMI выбирается отдельно.

Valve

Valve имитирует клапан. Создадим модель XV01 с двумя командами и двумя концевиками. Полный ход займёт три секунды.

Положение 0 — клапан закрыт, 100 — открыт. Подайте команды через PLC-компонент и проверьте концевики.

Если есть только команда открытия

Вместо отдельной команды закрытия передайте её отрицание:

Когда команда открытия исчезнет, модель начнёт закрытие. Сам PLC-компонент также должен быть настроен под однокомандный привод — по руководству компонента.

Методы модели клапана

Для проверки неисправности вызовите fail, подайте команду и дождитесь времени контроля хода ПЛК. После проверки верните normal.

Delay и выражения

Delay

Delay создаёт задержанный дискретный сигнал. Например, признак наличия потока должен появиться через две секунды после пуска насоса:

Объедините несколько команд

В командных входах моделей двигателя, клапана и задержки можно использовать выражения:

Например, включать модель от любой из двух команд, но только при наличии питания:

Модель читает выражение. В opc.write такое выражение передавать нельзя: у записи нужен один тег или NOT перед одним тегом.

Выражение передаётся прямо в параметр команды модели: set_start_tag, set_open_tag или set_close_tag. Модель сама вычисляет его по значениям тегов. Создавать отдельный объект для выражения не нужно.

Экспорт и генерация

Если в проекте десять одинаковых насосов, не нужно вручную переписывать сценарий десять раз. Сделайте один шаблон и передайте ему теги каждого насоса через таблицу «Экспорт MetaLab» компонента MetaGen.

Подготовьте шаблон

Создайте компонент MetaLab с именем PumpCheck. Заполните его таблицу сценария:

Фигурные скобки — места для подстановки. Конкретные теги появятся при генерации.

// {comment} — подпись экземпляра. Остальные строки с @ разбивают шаблон на секции.

Секции сценария

Сначала выполняйте MetaGen Init Objects. Он создаёт и настраивает модели, к которым обращаются проверки. При запуске всех сценариев генератор ставит его первым. Если запускаете проверки по отдельности, сначала сами выполните инициализацию.

Пуски, остановы и проверки аварий размещайте после @scenario, а не в @init.

Как объединяются проверки

При генерации через «Экспорт MetaLab» блоки всех экземпляров сначала собираются в общий документ MetaGen Scenario. При подготовке артефакта MetaLab одинаковые именованные секции этого документа объединяются.

Например, две проверки клапанов используют одну метку:

В Runtime появится один сценарий [MetaGen] Valves. В нём сначала будут действия XV01, затем XV02. Так можно объединить проверки всех клапанов проекта, сохранив отдельную группу для насосов.

Для объединения имена секций должны совпадать в точности.

Сценарий MetaGen Init Objects остаётся отдельным. Строки с маркерами сами не исполняются как команды.

Это объединение относится к блокам, собранным через экспорт MetaGen. Одинаковые названия секций в разных самостоятельных сценариях MetaLab не объединяют эти сценарии между собой.

Заполните экспорт

Откройте таблицу «Экспорт MetaLab» в проектном компоненте MetaGen. Для примера в его Params уже есть Id и FaultInput.

В Export до точки указывается имя компонента MetaLab — PumpCheck. После точки — имя подстановки из фигурных скобок. В Value — то, что нужно передать в сценарий.

Заполните две строки в Params:

Генератор создаст два блока проверки:

Для каждой используемой подстановки нужна одна привязка. Если забыть импортировать шаблон PumpCheck, оставить обязательное значение пустым или создать дубликат привязки, генерация сообщит об ошибке.

Три вида подстановок

Параметр может ссылаться на другой параметр. Например:

Программа получит ссылку PT01_Sensor_Inst.out_bError. Это связь алгоритма с датчиком, а не доступный для записи тестовый вход.

Есть и системный параметр |this| — имя проектного компонента MetaGen. Для компонента _03_Pumps он подставит _03_Pumps. Добавлять this в Params нельзя: имя зарезервировано.

Подготовьте теги

В Data у тегов, необходимых сценарию, должно быть Publish=1. После генерации они появятся в таблице OPC UA.

Берите имя из таблицы OPC UA. Не добавляйте к физическому IO имя GVL или лишнюю точку. Для внешнего ПЛК также выполните предусмотренную вашей платформой привязку адресов из инженерного экспорта.

Выполните генерацию

1. Импортируйте нужные шаблоны MetaLab.
2. Заполните Params и экспорт.
3. Сохраните проект и выполните генерацию MetaGen.
4. Сформируйте артефакт MetaLab и загрузите его в Runtime.
5. Проверьте наличие сценариев для нужного оборудования и запустите их.

Изменения вносите в исходный шаблон и экспорт. Готовые сценарии, созданные генератором, при следующей генерации будут заменены.

Доработка сценариев MetaKit

MetaKit содержит базовые сценарии. Перед запуском их нужно проверить и при необходимости изменить под конкретный объект. Они помогают проверить стандартный блок, но не знают всю технологию вашей установки.

Работайте с копиями компонентов и сценариев, импортированными в свой проект. Начните с простого:

Нормальное и аварийное значение

Каждому проверяемому каналу передаются два значения:

• Нормальное — чтобы подготовить исходное состояние.
• Аварийное — чтобы вызвать срабатывание.

Названия привязок зависят от компонента:

N заменяется номером канала. Например, для канала 1 компонента EngineUnit:

При необходимости можно передать числа. Но тег для записи тоже должен соответствовать проверке. Значение 12 не означает 12 бар, если записать его прямо в Raw.

Если авария вычисляется по давлению

Допустим, авария возникает, когда измеренное давление превышает предел. В само сравнение нельзя записать TRUE.

Выберите один способ:

• Передать в экспорт Raw-тег датчика и заранее рассчитанные значения Raw.
• Настроить модель датчика и изменить действие сценария на const_fv.
• Проверить эту защиту отдельным технологическим сценарием в автоматическом режиме.

Если модель PT01 настроена как в разделе о датчике, можно подать давление так:

Здесь нужно, чтобы предел был ниже 12 бар и канал защиты был разрешён. Две секунды — пример: задайте ожидание с учётом фильтра и задержки аварии. После возврата к нормальному давлению выполните сброс, если он предусмотрен.

Одной замены числа в экспорте недостаточно, чтобы opc.write стал const_fv: при смене способа воздействия изменяется и строка сценария.

Пример: сухой ход по уровню — от параметров до шагов

В учебной насосной станции канал 2 аварий насоса подключён к условию LT01_SensFilter_Inst.out_fY < Conf.Pumps_DryRunLevel. Уставка сухого хода — 10 %. Канал разрешён при исправном датчике. Записать TRUE в это сравнение нельзя: изменим уровень через модель датчика.

Изменения вносите в импортированные в свой проект компонент MetaGen и шаблон MetaLab. Библиотечные оригиналы менять не требуется. Для насосов станции используется VfdGroupEngineUnit, а имя его базового шаблона MetaLab — PidEngineUnit.

1. Добавьте параметры в таблицу Params насосов.

Это параметры проверки. Существующее условие защиты и её уставку в программе ПЛК сохраняем.

2. Измените три строки в таблице «Экспорт MetaLab».

Строку PidEngineUnit.fault2_input замените на PidEngineUnit.fault2_sensor. Две строки значений уже существуют — замените их значения ссылками на новые параметры.

После подстановки параметров сценарий получит имя модели LT01_Sensor и числа 50.0 и 5.0. Привязки шунта, задержки, выхода аварии и сброса остаются стандартными.

3. Замените действия, подающие сигнал на канал 2.

В проектном шаблоне PidEngineUnit найдите все записи opc.write с tag={fault2_input}. Замените их на вызовы модели. Сохраните назначение каждого значения:

У const_fv оставьте tag пустым, а число передайте через value. Метод задаёт значение в инженерных единицах; модель сама рассчитывает сигнал Raw по своей шкале и записывает его в исходный аналоговый вход. В выходы View сценарий не пишет.

Сохраните остальные шаги: ожидание, чтение аварии, проверку блокировки двигателя и сброс. Выдержка должна покрывать фильтрацию датчика, задержку защиты и цикл ПЛК. После восстановления уровня сбросьте защёлкнутую аварию штатной командой.

4. Сгенерируйте и выполните проверку.

Этот пример проверяет защиту, действующую и в ручном режиме. Ошибку датчика регулирования, действующую только в AUTO, проверяйте в пользовательском сценарии комплексной наладки. В стандартных регулирующих Units она уже исключена из автономного воздействия.

Если канал не проверяется автономно

Не удаляйте проверку канала из общего шаблона только ради одного объекта: этот шаблон может использоваться другими компонентами. В своей проектной копии можно изменить сценарий либо отключить конкретную проверку через экспорт.

При отключении через экспорт согласуйте все привязки канала: вход, шунт, задержку и выход передайте как FALSE, ожидаемое срабатывание — False, объект сообщения — //. Ожидание общего выхода фильтра тоже должно учитывать только проверяемые каналы.

У регулирующих Units MetaKit канал 8 с ошибкой датчика уже исключён из автономного воздействия. Защита в ПЛК продолжает действовать. У Units без регулятора обычный канал 8 проверяется как остальные.

Автономная и комплексная наладка

При автономной наладке проверяют отдельный механизм: ручной пуск и останов, обратную связь, местное/дистанционное управление, аварии и сброс.

При комплексной наладке проверяют установку в автоматическом режиме: общий пуск и останов, переключение на резервный насос, работу от датчиков и восстановление после нарушений. Для этого составляют свой сценарий с технологическими условиями и ожидаемыми результатами.

На страницах компонентов MetaKit доступны демо-проекты с примерами их применения. Скачайте проект из документации нужного компонента, чтобы посмотреть его параметры, связи и сценарии.

Проверка и ошибки

Для пробного выполнения без ПЛК есть Memory Mode. Он проверяет, что сценарий читается, объекты создаются и команды выполняются. Программы ПЛК в этом режиме нет — правильность аварий и управления он не доказывает.

Реакцию программы проверяйте с работающим MetaCore или внешним ПЛК. После прогона убедитесь, что сценарии завершились, ожидаемые значения совпали с прочитанными и оборудование осталось в нужном состоянии.

Если пропало соединение с OPC UA или не найден обязательный тег, реальный прогон останавливается. Не продолжайте оценку результатов по старым значениям — сначала восстановите подключение и проверьте, что программа работает.