(* Начиная с этой части я перешел на версию WinCC OA 3.17. Никаких отличий в масштабах базового курса не будет. Изменятся лишь надписи на скриншотах.*)
При создании типа точки данных Flap мы уже предусмотрели битовый DPE для аварии «Момент» (Flap→Alarms→Torque). Однако в настоящий момент для всех трех точек данных (Flap1, Flap2, Flap3) это всего лишь элемент, переменная. Для того, чтобы изменение этой переменной фиксировалось в подсистеме сообщений, необходимо повесить на этот DPE соответствующий конфиг. Для этого открываем модуль para и ищем наши точки данных.
Добавляем к DPE Torque точки данных Flap1 конфиг «Alert Handling»
Открываем настройки добавленного конфига. Обратите внимание, что внешний вид настройки Alert Handling зависит от типа переменной, к которой относится сам аларм. В настоящий момент мы работаем с типом данных bool, внешний вид окна следующий.
Good range касается значения самое переменной — какое из значений является «плохим» (т.е. при каком значении считаем, что аларм сработал), а какое — «хорошим» (аларма нет). Так же задаем текст при появлении аларма и его исчезновению. Зададим этот текст, как «came» (пришло) и «went» (ушло). За «хорошее» значение будем считать битовое значение «ложь», т.е. аларма нет.
Класс аларма — весьма важный параметр. Он определяет многие аспекты отображения сигнализации: какой будет цвет, задействовано ли мерцание, будет ли звуковое уведомление, требуется ли квитирование и т.д. Выбираем класс S7_Alarm и ставим галочку рядом со словом «Active». После выставления аларма активным все настройки становятся недоступны. Обратите внимание, что настройки активного аларма недоступны для редактирования не только на визуальной форме, но и средствами скриптов (а скриптами в WinCC OA можно много чего сделать, включая и динамическую работу с алармами). Настройки допускается менять только для неактивных алармов.
Перейдем в модуле para на конфиг original, посмотрим текущее значение и поменяем его на «истину».
Вернем значение переменной в FALSE. Текст аларма остается «came», продолжает мигать, изменилась лишь интенсивность его мигания.
Данный класс алармов подразумевает необходимость квитирования. Для подтверждения аларма в этом окне необходимо нажать кнопку Acknowledge, после чего все вернется в «нормальное» состояние.
Возникает вопрос — где можно ознакомиться с настройками каждого класса алармов? Как можно модифицировать существующий класс алармов или задать свой класс? Это реализуется через точки данных (вообще любые настройки системы живут либо в точках данных, либо в конфиг-файлах). Ну, а если что-то доступно через точки данных, то это что-то вполне возможно модифицировать через программный код. Правда, сейчас мы этого делать не будем. Лучше посмотрим модуль para и поищем нужные точки данных.
На первый взгляд тут есть много точек данных, но где же DP, ответственные за классы алармов? Выставляем галочку Internal datapoints (внутренние точки данных) и видим, что полку точек данных заметно прибыло.
Ищем точки данных типа _AlertClass, тут и содержатся все классы алармов, которые можно изменить (на свой страх и риск, разумеется), либо создать свой новый класс. Поскольку мы выбрали для нашего единственного аларма класс S7Alarm, смотрим его настройки, развернув соответствующую точку данных.
Тут и задается приоритет класса, сохранение алармов, необходимость квитирования, надо ли квитировать «прошлые» алармы, если тревога возникала неоднократно до действий оператора, цвет и шрифт текст алармов и т.д.
Только что мы смотрели, как работают алармы в модуле para. Это очень интересно и познавательно для разработчика, однако не очень удобно. Ознакомимся еще с одним способом просмотреть список событий. Для этого в меню gedi найдем и нажмем кнопку System Management
Перейдем в Diagnostics
Откроем Alarmscreen
И в появившемся окне нажмем на зеленый треугольник внизу панели
Откроем модуль para, найдем Flap1.Alarms.Torque и поиграем с его значениями
В окне Alarmscreen можно сквитировать алармы. По умолчанию данное окно показывает только текущие тревоги. Если активных алармов нет, а все старые уже сквитированы, то список пуст. Для того, чтобы изменить представление, необходимо нажать кнопку с отверткой и гаечным ключом внизу панели. В этих свойствах очень много закладок и очень много настроек. И все они касаются одних только алармов.
Если задать Time range в Open и выбрать Historical Data, то мы сможем увидеть историю алармов.
В связи с тем, что тема алармов весьма обширная, а это всего лишь первый взгляд, не стоит удивляться некоторым непонятным вещам. Например, мне самому непонятно, почему в этой таблице Alarm text у нас везде состоит из одного слова «came» (нуууу… когда-нибудь, наверное, может быть, если фаза луны сойдется, то разберусь).
Alarmscreen тоже очень интересен. Смотреть на нем алармы куда лучше, чем в модуле para. Однако, мы делаем конечное приложение для конечного пользователя, т.е. для оператора. Удобно ли будет оператору каждый раз открывать через менюшки отдельное окно аварий? Лично я в этом сильно сомневаюсь. Давайте лучше займемся интеграцией окна сообщений в наше приложение пользователя.
Перейдем обратно в редактор gedi и откроем созданную ранее панель Flaps. Далее посмотрим внимательно на левую часть редактора gedi. Кроме нашего проекта (у меня он называется Workshop) есть еще один проект с названием 3.17 (в самом начале этой главы я уже признался, что перешел на новую версию, а так был бы проект с названием «3.16»), который мы точно сами не создавали. Его можно развернуть и поизучать, там много всего интересного — скриптов, библиотек, панелей и т.д. Пытливые умы потратят немало времени на ознакомление.
По сути, это и есть «ядро» системы WinCC OA. Этот проект содержит все или почти все, относящееся к самой платформе — gedi, para, панель Project Administrator, панель консоли, вся логика. И, вуаля, всем этим можно пользоваться в своих приложениях. Вот, например, я открыл в редакторе gedi панель para. Его можно изменить. И использовать в своих целях измененную копию. Про модификацию стандартных (или системных?) компонент WinCC OA поговорим чуть попозже в этой же части. А сейчас наша задача — разместить окно с алармами в окне пользовательского приложения.
Для этого в дереве «системного» проекта 3.17 ищем панель по следующему пути: 3.17 (версия Вашей копии WinCC OA) → Panels → vision → aes → AESRow.pnl. Перетаскиваем ее на свободное место открытой панели Flaps. Система попросит задать значение $-параметра $SCREENTYPE. Цинично проигнорируем эту просьбу, нажав кнопку Cancel.
Внизу у нас появился небольшой элемент отображения
Проверим, работает ли оно вообще, для чего зададим в модуле para значение «истина» для аварийного сигнала.
Теперь поговорим немного о модификации стандартных компонент WinCC OA. Например, сейчас я растянул в высоту окно отображения алармов. В нем добавилось строк, однако кнопки и цифры в правой части растянулись в высоту, что плохо влияет на эстетику. Упростим себе задачу и просто уберем эти кнопки.
Для этого в редакторе gedi кликнем правой кнопкой на AESRow и выберем Open panel reference
Откроется «оригинальная» панель
Удалим «некрасивые» кнопки и цифры
Нажмем Save и увидим следующее окно
Ответим утвердительно, после чего редактируемая нами панель сохранится в виде копии в структуре нашего проекта «Workshop», а не по «системному» пути. В нашем проекте мы будем работать с этой копией. Теоритечески можно сохранять по системному пути (например, путем подмены файлов), то эти изменения становятся общими для всех проектов WinCC OA, что нежелательно. Особенно негативно сохранение по системному пути, а не в виде локальной копии, может сказаться после установки патчей. Патчи могут корректировать, в том числе, и системный проект, и даже ту панель, которую вы изменили. Вероятность этого всегда отлична от нуля. Соответственно, устанавливая патч, вы рискуете утратить свои изменения, если сохранили их в системный проект.
Есть еще один нюанс, связанный с модификацией системных панелей и патчами. Если вы работаете с локальной сохраненной копией проекта, то натравленный на систему патч исправит только «системный» проект, но не вашу локальную копию панели.
В общем, модификация ядра — это ответственное занятие, требующее внимательности. Не забывайте читать readme патчей, затронуты ли там модифицированные вами панели. У вас в руках очень мощный инструмент, но пользоваться им надо уметь.
После внесения изменений в панель AESRow нашу панель Flaps необходимо переоткрыть, чтобы изменения «вложенной» панели вступили в силу.
Последний пример в этой части — визуализация пиктограмм технологического оборудования, находящегося в аварином состоянии, тем же способом (цвет, мерцание и т.д.), который задан соответствующему классу аварий. Для этой демонстрации разместим на панели Flaps окружность (Circle).
Зададим динамизацию события Initialize через визард, как уже делали ранее для задвижки. Выбираем в визарде Change color
Выбираем Background color и Alert Handling, жмем Next. Выбор Alert Handling позволит системе подтянуть значение цвета от аларма.
Выбираем Datapoint element
Жмем Next, а в следующем окне — Finish. Запускаем на проверку и смотрим, что получилось. В настоящий момент аларм у меня активен и не подтвержден, круг быстро моргает серым и красным (как и класс алармов S7_Alarm).
После подтверждения аварии он перестает моргать, после ухода аварии (соответствующей переменной дали значение «ложь») становится белым, а в нижней части экрана аларм пропадает из списка.
Взглянем на полученный скрипт
В данном случае происходит подписка на актуальный цвет аларма из соответствующего конфига, который назначается непосредственно в качестве фонового цвета нашего графического объекта.
