Оптимизация производительности — различия между версиями

Версия 13:28, 10 июля 2015

Для понимания принципов работы WebHMI давайте разберем как работает ее ядро.

Схематично структуру ядра системы можно изобразить так:

Ядро работает циклично. Это значит что все действия выполняются последовательно. Если на каком-то из этапов возникают задержки то это оказывает влияние на время выполнения всего цикла.

Давайте рассмотрим каждый из блоков этой диаграммы.

Чтение конфигурации

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

Когда настройки проекта прочитаны ядро входит в главный цикл.

Запись новых значений в регистры

В начале цикла происходит запись новых значений в регистры. В системе есть специальная очередь для записи новых значений в регистры. Есть 2 способа записать данные в регистр - через API и через сценарии. В обоих случаях запись происходит не в тот момент когда поступает запрос (т.к. система может быть не готова к этому, например по RS-485 в данный момент уже идет обмен с ПЛК) а позже, в подходящее для этого время. Запрос на запись поступает в очередь. Все запросы на запись будут выполнены в начале следующего главного цикла.

Чтение регистров

Далее происходит чтение регистров из внешних устройств и внутренних регистров WebHMI. Регистры читаются группами. Группировка происходит по их Соединению. Например, если в проекте есть соединение с ПЛК Delta, ПЛК Siemens и внутренние регистры WebHMI то чтение будет выглядеть так:

1. Читаются все регистры из ПЛК Delta
2. Читаются все регистры из ПЛК Siemens
3. Читаются все внутренние регистры WebHMI

Внутренние регистры WebHMI читаются всегда последними (т.к. в них есть регистры C0, C1, C2... в которых хранятся ошибки чтения из остальных соединений).

Сразу после чтения происходят необходимые преобразования значений (умножение, добавления константы, приведение типов и т.п.).

Если для любого из соединений указана стабилизационная пауза то перед чтением группы регистров этого соединения произойдет соответствующая пауза. Это иногда необходимо для стабильной работы разнородных устройств на одной шине RS-485. Без этой паузы некоторый устройства могут не успеть определить начало кадра сообщения и пропускать первый пакет на чтение первого регистра.

Также у соединений есть настройка Таймаут. Это время, которое система будет ждать ответа от устройств на свой запрос. Если устройства не ответили за указанный промежуток времени или ответили не весь пакет данных то система будет считать что регистр не прочитался. Его значение будет выставлено в -1, а статус регистра в invalid.

Это значит что если нет связи с одним из внешних устройств то общее время опроса (минимальная длина главного цикла) увеличится на Timeout × Количество регистров в этом соединении.

Пример. У нас есть подключение к ПЛК Delta SX2 по ModBus RTU. Мы читаем из него 5 регистров на скорости 115200. Timeout установлен в 100 мс. Среднее время чтения всех пяти регистров составляет 30 мс (посмотреть его можно во внутреннем регистре WebHMI T1). Если связь с ПЛК пропадет по любой из причин то среднее время чтения всех пяти регистров теоретически увеличится до 5 × 100 мс = 500 мс (а на практике будет примерно 525 мс).

Это означает что если в проекте есть опрос неподключенного устройства то это замедлит весь цикл на существенное количество времени. Если необходимо минимизировать эту задержу то необходимо максимально увеличивать скорость обмена и уменьшать Timeout и Stabilization pause. Но лучше всего - или восстановить связь с устройством или отключить это соединение в настройках.

Выполнение сценариев

После того как регистры были прочитаны ядро выполняет сценарии. Сценарии выполняются очень быстро и задержек здесь быть не должно при разумном количестве и сложности сценариев. Единственная особенность на которую следует обратить внимание - это различие в механизме работы операций Set и Write.

Операция Set поменяет значение указанного регистра сразу же, в этом же месте главного цикла. Причем поменяет значение только в оперативной памяти ядра. Новое значение не будет записано во внешние устройства и будет доступно только до конца текущего цикла.

Операция Write делает все то же самое то и Set с тем лишь отличием что добавляет команду на запись нового значения в очередь записи. И в начале следующего цикла это значение будет записано в соответствующий регистр внешнего устройства.

Вычисление состояний регистров

К этому моменту главного цикла уже значения всех регистров вычислены и дальше меняться не будут. Поэтому именно в этом месте вычисляются состояния для каждого регистра (invalid / disabled / normal / warning / alert).

Обработка событий

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