Стандарт программирования проектов MetaPlatform / MetaLib

1. Глобальные области проекта

Область Назначение Пример
Conf Конфигурационные переменные проекта Conf.Pump1_Engine_diStartDelayTime
View Параметры ФБ и опубликованные сигналы IO View.Pump1_Engine_Inst_out_bState := Pump1_Engine_Inst.out_bState

2. Обозначения

Обозначение Смысл Пример
ID Идентификатор объекта, механизма, группы, датчика или общего блока **<ID>**_Engine_Inst → Pump1_Engine_Inst
Class Тип функционального блока без префикса C <ID>_**<Class>**_Inst → Pump1_Engine_Inst
Access Область параметра блока: in, out, inout <ID>_<Class>_Inst_**<Access>**_bState → Pump1_Engine_Inst_out_bState
Signal Имя сигнала DI_<ID>_<ТипДанных>**<Signal>** → DI_YA1_bStateOpen
Parameter Имя параметра <ID>_<Class>_<ТипДанных>**<Parameter>** → Pump1_Engine_diStartDelayTime
ТипДанных Префикс типа данных <ID>_<Class>_**<ТипДанных>**StartDelayTime → Pump1_Engine_diStartDelayTime

3. Именование

3.1. Префиксы типов данных

Тип данных Префикс Пример
Bool b bStart
Byte by byState
Word w wAlarmTag0
DWord dw dwFlags
Int i iMode
UInt ui uiCount
DInt di diDelay
UDInt udi udiTimeout
Real f fSP

3.2. Общие правила

Правило Требование Пример
Символ . Не использовать в программном ID Pump1_Engine_Inst_out_bState, не Pump1.Engine.Inst.out_bState
Спецсимволы Не использовать Допускается только _
Начало имени Не начинать с цифры Pump1_Engine_Inst, не 1Pump_Engine_Inst
Массивы Использовать p + префикс типа pwAlarm
Таймеры Использовать тип DInt diDelay, diTime
Константы Писать заглавными буквами без префикса типа STATESTOPPED, ADC_MAX_VALUE
Функции Писать со строчной буквы getWorkingCount(), makeView()
Функциональные блоки и экземпляры Писать с заглавной буквы General, Sens, Pump1_Engine_Inst()

3.3. Сигналы IO

Правила этого подраздела являются общими для целевых платформ. Особенности физической адресации платформ не изменяют имена тегов.

В итоговом проекте ПЛК различаются Raw-теги физических каналов и логические теги технологических сигналов. Оба вида являются глобальными тегами. Место их объявления определяется пользователем в целевой среде разработки ПЛК.

MetaPlatform работает только с логическими тегами. Raw-теги не входят в канонический проект MetaPlatform, не публикуются и не используются таблицами MetaGen.

3.3.1. Raw-теги

Raw-тег однозначно идентифицирует физический канал ПЛК и не содержит технологического назначения сигнала. Raw-теги объявляются непосредственно в целевой среде разработки ПЛК.

Шаблон:

<PLC>_<Module>_<Channel>

Примеры:

Требования:

3.3.2. Логические теги

Логический тег описывает технологическое назначение сигнала и не зависит от номера физического модуля или канала. MetaPlatform подключает логические теги как внешние глобальные теги и не определяет место их объявления в проекте ПЛК.

Шаблон:

(DI|DQ|AI|AQ)_[<ID>_]<ТипДанных><Signal>

Примеры:

Требования:

Для одинаковых сигналов однотипных исполнительных механизмов используется один и тот же суффикс. Имена отличаются только префиксом направления сигнала и нормализованным ID исполнительного механизма.

Стандартные суффиксы:

Примеры:

Обозначения на схеме «Пуск/стоп» и «Открыть/закрыть» не переносятся в логический тег как составные суффиксы. Для удерживаемого выхода пуска используется bStart, для выхода открытия — bOpen. Суффиксы bStartStop, bOpenClose и bClosed для этих стандартных сигналов не применяются.

3.3.3. Нормализация ID и KKS

В программном имени использовать латинские буквы, цифры и символ _. Точки внутри числовой части удаляются. Структурные дефисы и пробелы заменяются символом _. Повторяющиеся _ сводятся к одному, символы _ в начале и конце имени удаляются.

Примеры:

Исходное обозначение без нормализации сохраняется в KKS, наименовании сигнала и инженерном комментарии.

3.3.4. Маппинг

Связь Raw-тегов физических каналов с логическими тегами выполняется функцией маппинга, создаваемой в целевой среде разработки ПЛК вне канонического проекта MetaPlatform:

Raw-теги и функция маппинга являются частью итогового проекта ПЛК, но не являются исходными или генерируемыми сущностями MetaPlatform.

3.3.5. Единственная точка подключения IO

В прикладной логике каждый логический аналоговый или дискретный вход подключается к обрабатывающему компоненту один раз. Дальнейшие потребители используют выход этого компонента. Для измерения используется обработанное значение Sensor/SensFilter; для аварийного или предупредительного сигнала — выход соответствующего канала SignalsFilter.

Каждый логический выход записывается одним компонентом. Требования нескольких потребителей объединяются до формирования этого выхода.

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

3.4. Библиотечные блоки, проектные блоки и экземпляры

Библиотечные многократно используемые блоки имеют префикс C.

Примеры: - CEngine - CValve - CControlValve - CPID - CPIDD - CCascade - CCascadeUnit - CCabinetController

Проектные блоки префикс C не имеют.

Примеры: - General - Sens - Heating - Feed - Boilers

Шаблон имени экземпляра: <ID>_<Class>_Inst

Примеры: - Overheat_TwoStep_Inst - PumpSwitch_Delay_Inst

Исключение: - CabinetController_Inst — один на ПЛК, используется фиксированное имя.

3.5. Параметры функций и ФБ

Параметры функций и функциональных блоков имеют префиксы: - in_ - out_ - inout_

Параметры inout_* используются только для управления с HMI.

Примеры: - in_bEnable - out_bState - inout_bStart - inout_iRemoteMode

3.6. Сокращения Class

В одном проекте сокращения должны использоваться однотипно.

Class Сокращение
SensorFilter SensFilter
SignalsFilter SgnlsFltr
ControlValve CtrlValve
CabinetController CabinetController
CascadeUnit CascadeUnit

3.7. Именование переменных в Conf

Шаблон: <ID>_<Class>_<ТипДанных><Parameter>

Примеры: - Pump1_Engine_diStartDelayTime - Pump1_Engine_diStopDelayTime - YA5_Valve_bNO - Boilers_Cascade_diConnectionDelay - Outdoor_T_SensFilter_iCount - General_Flts_SgnlsFltr_bCO_L2_Bypass - CabinetController_diPowerControlFilter

Если параметр относится к конкретному сигналу внутри блока, имя сигнала входит в Parameter.

Примеры: - General_Flts_SgnlsFltr_bCO_L2_Bypass - General_Flts_SgnlsFltr_diCO_L2_Delay - General_Wrns_SgnlsFltr_bSensorError_Bypass

3.8. Именование переменных в View

Шаблон: <ID>_<Class>_Inst_<Access>_<ТипДанных><Parameter>

Примеры: - Pump1_Engine_Inst_out_bState - Pump1_Engine_Inst_out_diWorktime - Pump1_Engine_Inst_inout_bStart - Boiler_CascadeUnit_Inst_out_fPower - YA1_Valve_Inst_out_iMode - YA1_Valve_Inst_inout_bOpen

Для сигналов IO имя не изменяется.

Примеры: - View.DI_GasJet_bMode := DI_GasJet_bMode - View.DQ_MSV_bOpen := DQ_MSV_bOpen

Для параметров ФБ во View сохраняется полное имя экземпляра и параметра.

Пример: - View.Pump1_Engine_Inst_out_bState := Pump1_Engine_Inst.out_bState

3.9. Пользовательские комментарии

Исходный KKS сохраняется в пользовательском комментарии без нормализации. Основной Comment является полным пользовательским названием и строится по шаблону:

<исходный KKS> <функциональное наименование>

Примеры:

В функциональном наименовании не повторяются KKS и уже заданный им порядковый номер. В основной Comment не добавляются названия шаблонов и библиотечных классов.

MetaKit может добавлять названия отдельных внутренних функций, например . ПИД, . Фильтр, . Элемент каскада, . Аварии и . Предупреждения. Название основного механизма или датчика повторно не добавляется.

Примеры итоговых комментариев:

Не допускаются комментарии вида K4.1 Насос K4.1, Клапан отопления. Клапан или Давление. Датчик аналоговый.

3.10. Семантика аварийных и предупредительных сигналов

На входы аварий и предупреждений стандартных компонентов передаётся TRUE при наличии соответствующего события.

Raw-тег сохраняет фактическое электрическое состояние входа ПЛК. Если физический аварийный или предупредительный сигнал выполнен нормально замкнутым контактом, он инвертируется в точке подключения к компоненту.

Пример:

FltIn := NOT DI_VFD_bFault

Инверсия выполняется в выражении таблицы параметров или в предусмотренной точке подключения сигнала. Логика компонента и физический Raw-тег ради этого не изменяются. Тип контакта определяется по принятой IO-таблице и рабочей документации, а не предполагается по имени сигнала.

4. Стандарт временных параметров ФБ

Если функциональному блоку требуется параметр времени, задержки, таймаута, периода, длительности импульса или другой временной настройки, такой параметр должен задаваться через тип DInt.

Сам параметр во входном интерфейсе ФБ также должен иметь тип DInt.

Time не используется как тип внешнего параметра проектных и библиотечных ФБ.

4.1. Правило именования временных параметров

Временные параметры именуются с префиксом типа данных di.

Примеры:

4.2. Источник временных параметров

Настройки времени и задержек проекта должны храниться в Conf как DInt.

Примеры:

Pump1_Engine_diStartDelayTime : DInt;
Pump1_Engine_diStopDelayTime : DInt;
YA1_Valve_diOpenDelayTime : DInt;
YA1_Valve_diCloseDelayTime : DInt;

4.3. Передача временных параметров в ФБ

Если ФБ требует временную настройку, в его параметр передаётся значение типа DInt.

Правильно:

Pump1_Engine_Inst(
    in_diStartDelayTime := Conf.Pump1_Engine_diStartDelayTime,
    in_diStopDelayTime := Conf.Pump1_Engine_diStopDelayTime
);

Неправильно:

Pump1_Engine_Inst(
    in_tStartDelayTime := T#5s,
    in_tStopDelayTime := T#3s
);

Неправильно:

Pump1_Engine_Inst(
    in_tStartDelayTime := DINT_TO_TIME(Conf.Pump1_Engine_diStartDelayTime)
);

4.4. Применение _DIntToTimeSafe

_DIntToTimeSafe используется только в том месте, где значение DInt фактически передаётся в таймер или системный параметр типа Time.

То есть внешний интерфейс ФБ остаётся DInt, а преобразование в Time выполняется внутри реализации ФБ.

Правильно внутри реализации ФБ:

StartDelay_Timer_Inst(
    IN := in_bStart,
    PT := _DIntToTimeSafe(in_diStartDelayTime)
);

Неправильно выносить Time наружу в интерфейс ФБ:

VAR_INPUT
    in_tStartDelayTime : Time;
END_VAR

Правильно:

VAR_INPUT
    in_diStartDelayTime : DInt;
END_VAR

4.5. Что не допускается

Не допускается: