Создание и настройка UDM-регистра

24 июня 2014

 

Поделитесь статьей в социальных сетях

0

Данная статья посвящена созданию и настройке UDM-регистра в GENESIS64. Глядя на количество настроек регистра, довольно непросто признать, что процесс его настройки может вызвать какие-либо сложности. Однако пресловутая пусконаладка и возникающие осложнения в ходе нее говорят об обратном. Оказывается, и здесь не обходится без «подводных камней».

Итак, обычный UDM-регистр создается командой Register в одноименном разделе UDM-конфигурации и содержит 2 вкладки: свойства и настройки входа/выхода.

Регистр

 

Свойства регистра

  • Name — просто его название.
  • Description — его описание в произвольной форме.
  • Data Type — тип данных. Можно выбрать конкретный тип или оставить значение Native. Относится, скорее, к выходному параметру регистра.
  • Propagation Style — условие использование входного значения регистра. Допустимы варианты: абсолютное использование или отключение входа, а также в зависимости от другого тега.

Свойства регистра

 

Вход/выход регистра

  • Input Tag позволяет включить или выключить вход регистра. В значении None мы можем выключить вход, а при необходимости задать начальное значение в поле Use Initial Value. Что позволит использовать данный регистр в качестве внутренней ячейки хранения данных (выход должен быть запрещен).
  • OPC Data Tag.  Поле Input OPC Data Tag содержит путь к ОРС или другому тегу. Required Data Type имеет то же значение, что и Data Type во вкладке свойств регистра, но имеет над ним приоритет. Scan Rate задает частоту чтения тега указанного в поле Input OPC Data Tag. Поле Input Delay учитывает задержку на чтение входного значения со сдвигом вправо по оси времени относительно значения Scan Rate.

Для чего нужна задержка? Я не вижу особенного смысла в использовании этой функции, если задействован только вход регистра. Смысл есть в том случае, если у регистра задействованы как вход, так и выход, и оба ссылаются на один и тот же ОРС-тег. Допустим, на выход регистра подано новое значение, далее UDM передает это значение в ОРС-сервер, которое сервер записывает в переменную ПЛК по заранее известному адресу. Помним, что вход регистра ссылается на тот же тег! В момент прохождения всей цепочки высоковероятно наступление очередного прочтения значения ОРС-тега входом регистра. НО! Новое значение еще не попало в переменную ПЛК, а вход регистра уже прочитал новое значение. Что не соответствует действительности, и оператор видит на экране нереальную картину техпроцесса.

В описанном примере значение Input Delay помогает избежать неприятностей.

  • Output Tag отвечает за выходное значение регистра.

Enable активирует выход.

Output Tag содержит путь к тегу.

Refresh Output указывает частоту отправки значения регистра на его выход независимо от того, изменилось значение регистра или нет. Функцию стоит использовать очень осмотрительно и не для всех типов сигналов. Например, для команды на включение/выключение двигателя рекомендуется выключать данную функцию. Увеличение сетевого трафика и нагрузки на ОРС-сервер станут следствием использования Refresh Output.

  •  Tags Management

Realese tag when not in use позволит снизить нагрузку на ОРС-сервер и освободить точки лицензии. Последний факт не может не радовать. В случае использования регистра помимо экранной формы и в других модулях GENESIS64 (TrendWorX64, AlarmWorX64 и др.) тег будет активен в любом случае.

Вход/выход регистра

По ходу статьи может сложиться впечатление, что ОРС-сервер является неким «недотрогой», к которому требуется трепетное отношение. На самом деле это не так, просто ОРС-сервер выступает в роли связующего между уровнями системы управления и вынужден подстраиваться под обе стороны. С одной стороны сервер обязан ответить на все поступающие к нему запросы со стороны клиентов, а с другой получить ответ от ПЛК.

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

Как видим, ОРС-сервер становится заложником ситуации. А некоторые вышеперечисленные настройки регистра позволят увеличить эффективность взаимодействия SCADA-системы и ОРС-сервера.

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


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*