5.1. global — исходный сигнал и копия для экрана
global связывает строку Data с уже объявленной глобальной переменной. Само объявление остаётся в GVL или DB; строка не создаёт его повторно.
У опубликованной глобальной переменной два назначения. MetaLab меняет исходный вход программы, а MetaView показывает его копию из View. При Publish = 1 генератор готовит эти связи отдельно.
Рассмотрим Tag = fRaw1, Area = Signals. Сам вход уже объявлен в GVL или DB Signals.
| Где | Имя или адрес | Что происходит |
|---|---|---|
| Программа ПЛК | Signals.fRaw1 |
Алгоритм читает исходное измерение |
| Сценарий MetaLab | fRaw1 |
Имитатор обращается к логическому имени входа |
| Таблица ML OPC UA | name = fRaw1, area = Signals |
Этому имени назначается адрес исходного Signals.fRaw1 из экспорта среды разработки |
makeView |
View.Signals_fRaw1 := Signals.fRaw1; |
Значение входа копируется для отображения |
| Карточка MetaView | View.Signals_fRaw1 |
Индикатор читает копию измерения |
Имя в сценарии не является адресом OPC UA. MetaLab берёт fRaw1, находит строку с этим именем в своей таблице тегов и обращается по указанному там nodeId. Адрес может отличаться в CODESYS и Siemens, а логическое имя в сценарии остаётся прежним. Area указывает GVL или DB для поиска нужного исходного тега; в имя сценария её добавлять не нужно.
Например, в полученном из TIA экспорте исходному Signals.fRaw1 соответствует ns=3;s="Signals"."fRaw1". Это адрес исходной переменной, а не поля View. Не вводите его вручную: адреса берутся из экспорта вашего проекта.
У копии для экрана правило именования другое:
| Area в Data | Исходный тег | Имя в сценарии MetaLab | Копия для MetaView |
|---|---|---|---|
| Пусто | fRaw1 |
fRaw1 |
View.fRaw1 |
Signals |
Signals.fRaw1 |
fRaw1 |
View.Signals_fRaw1 |
Таблица показывает два варианта публикации одного входа. В одном проекте логические имена в ML OPC UA должны быть уникальны: два разных входа из разных DB нельзя назвать одним fRaw1 в сценариях.
При штатной публикации global в HMI Tags для MetaView попадает копия View.…. Исходный fRaw1 из таблицы ML OPC UA напрямую в привязках экрана не используется: MetaView получает свои адреса из HMI Tags. Для измерения на экране нужна именно отображаемая копия.
Синус записываем в fRaw1, а не в View.Signals_fRaw1. Копию каждый цикл обновляет makeView; запись в неё будет перезаписана и не изменит исходный вход алгоритма. Это относится к копиям global. Настройки Conf и команды ref/inout по-прежнему можно изменять с экрана.
Чем отличаются CODESYS и Siemens
Логическое имя fRaw1 в сценарии одинаково для обеих платформ. Различаются место хранения исходного входа, обращение к нему в ST и формат файла с адресами.
| Что сравниваем | CODESYS 3.5 | Siemens TIA Portal |
|---|---|---|
| Где объявлен исходный вход примера | GVL Signals |
DB Signals |
| Обращение в ST | Signals.fRaw1; допустимо короткое fRaw1, если оно однозначно, не перекрыто локальной переменной и GVL не требует qualified_only |
Signals.fRaw1 или "Signals".fRaw1: для поля DB необходимо имя блока |
Area у строки global |
Можно оставить пустой при обращении по короткому имени. Signals явно задаёт GVL для генерируемых обращений и поиска в экспорте |
Для поля DB в нашем примере укажите Signals, а в Tag — fRaw1 |
Копия при Area = Signals |
View.Signals_fRaw1 |
View.Signals_fRaw1 |
| Имя в сценарии и ML OPC UA | fRaw1 |
fRaw1 |
| Откуда берётся адрес OPC UA | XML символьной конфигурации — Symbolconfiguration |
Экспорт OPC UA XML — UANodeSet |
| Что опубликовать на сервере | Нужные глобальные входы и данные Conf/View через символьную конфигурацию |
Нужные переменные DB Signals, Conf и View с доступом HMI/OPC UA |
Правило сопоставления для обеих платформ: при Area = Signals ищем исходный Signals.fRaw1; при пустой области короткое имя должно однозначно определять исходный тег. Уже полное имя сопоставляется напрямую. Найденный адрес записывается в ML OPC UA, а имя сценария не меняется. Доступность короткого имени при поиске в XML не отменяет требований ST: поле Siemens DB в коде всё равно указывается через имя DB.
У Siemens бывают также PLC-теги из таблицы тегов, доступные по собственному имени. Это другой случай; здесь разбираем наш вход внутри DB Signals.
Area влияет на генерируемые обращения, например в makeView, но не переписывает пользовательский ST Template. При переносе этого примера из CODESYS в Siemens обращение fRaw1 в алгоритме нужно записать как Signals.fRaw1. При этом сценарий MetaLab продолжает использовать fRaw1.
Особенность CODESYS описана в справке по qualified_only. Сравнение импорта OPC UA в этой таблице относится к CODESYS 3.5; экспорт для CODESYS 2.3 рассматривается отдельно.
Что экспортировать из среды разработки
Для совместной работы MetaLab и визуализации одного View недостаточно. В публикации OPC UA должны присутствовать:
| Какие данные | Для чего |
|---|---|
Исходные глобальные теги, например Signals.fRaw1 и Signals.fRaw2 |
MetaLab подаёт имитируемые сигналы в программу; для этого нужна запись |
Conf |
Чтение и изменение настроек |
View |
Отображение копий и результатов; чтение и запись предусмотренных команд |
В CODESYS включите нужные глобальные переменные вместе с Conf и View в символьную конфигурацию и экспорт. В Siemens обеспечьте доступ по OPC UA к соответствующим переменным DB и экспортируйте их описание. Полученный XML нужен MetaPlatform для сопоставления логических имён с адресами сервера. Права сервера должны разрешать запись в имитируемые входы.
При генерации для MetaCore адреса для MetaLab и визуализации формируются автоматически; отдельный XML из среды разработки не требуется.