Залипшая команда кнопки HMI при потере связи

Оператор нажал экранную кнопку ручного движения и отпустил её, но механизм продолжил работать. В программе осталась единица: запись нажатия дошла, а запись отпускания потерялась при разрыве связи. Для кнопки из двух сетевых событий такой отказ вполне возможен, даже если анимация на панели уже вернулась в исходное состояние.

Разберём обычные команды HMI, подтверждение приёма и ограничение времени действия. Управление от нескольких визуализаций здесь не рассматриваем. Экранная кнопка и описанные программные меры не заменяют предусмотренные проектом функции безопасности и аварийного останова.

Короткий ответ

Нельзя считать, что событие отпускания экранной кнопки обязательно дойдёт до ПЛК. Одноразовую команду лучше передавать как запрос с подтверждением и обработкой на стороне контроллера. Для удерживаемого действия требуется контролируемое продолжение разрешения с ограниченным сроком, если такая модель допустима для механизма. Потеря связи, истечение срока и смена владельца управления должны иметь определённую реакцию. После восстановления связи старую команду не следует автоматически считать новым намерением оператора.

Где возникает залипание

Простейшая кнопка записывает TRUE при нажатии и FALSE при отпускании. Между этими событиями находятся обработка интерфейса, очередь драйвера, сеть и цикл контроллера. Разрыв на любом участке может разделить пару. Факт локального отпускания пальца не доказывает, что сервер получил вторую запись.

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

На стороне контроллера команда иногда непосредственно управляет выходом. Тогда оставшаяся единица сохраняет действие до следующей записи или другой блокировки. Если команда ещё и ретентная, перезапуск может добавить неожиданный сценарий. Хранение сетевого запроса и хранение состояния технологического автомата нужно рассматривать отдельно.

Обратная связь от механизма не устраняет проблему намерения. Она показывает, что исполнитель включён или движется, но не доказывает, что оператор продолжает разрешать движение. Для устойчивой схемы нужны понятные границы между запросом, принятием, состоянием и физическим подтверждением.

Одноразовая команда

Для запроса вроде «начать цикл» удобно, когда HMI отправляет идентифицируемое намерение, а ПЛК принимает или отклоняет его и выдаёт результат. Контроллер проверяет режим, разрешения и текущее состояние. После обработки запрос не должен оставаться постоянным разрешением на повторный запуск.

Простой вариант Set/Reset, где HMI устанавливает бит, а контроллер сбрасывает его после обработки, убирает зависимость от записи отпускания для одноразового события. Но остаются вопросы повторной доставки, одновременных записей и отображения результата. Для ответственных прикладных операций полезнее номер запроса и отдельный номер подтверждения.

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

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

Удерживаемое действие

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

Срок выбирают с учётом допустимого движения после потери управления, задержек связи и цикла программы. Нельзя просто взять удобную секунду и объявить её безопасной. Для некоторых механизмов обычная сеть и программный контроль вообще не подходят для требуемого режима; решение принимают в проекте управления и безопасности.

Условно при скорости 0,05 м/с и задержке реакции 0,4 с дополнительное перемещение до начала торможения составляет 0,02 м. Это лишь кинематическая иллюстрация: реальный путь включает время исполнительного устройства и торможение. Такой расчёт помогает увидеть, почему сетевой таймер нельзя выбирать только ради отсутствия ложных отключений.

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

Состояния и ответственность

Право записи команды следует закрепить за определённым источником. Даже при одной панели в проекте могут существовать сервисный клиент, инженерная среда или удалённое приложение. Если несколько участников записывают один бит, сброс одним из них не гарантирует, что другой не установит его снова.

Не стоит давать панели прямой доступ к физическому выходу только ради удобного ручного экрана. Запрос проходит через логику контроллера, где проверяются режимы и технологические условия. Требования к защитным функциям реализуют предусмотренными средствами; обычная программная проверка HMI-команды не приобретает от этого статус функции безопасности.

Стендовые испытания потери связи

Проверку проводят на безопасном стенде или по согласованной процедуре без опасного движения. Для каждого сценария записывают время нажатия, принятия запроса, разрыва, прекращения действия и восстановления. Простое наблюдение зелёной кнопки не даёт достаточного протокола.

Первый разрыв выполняют до доставки нажатия: действие не должно возникнуть позднее из старой очереди без допустимого нового намерения. Второй разрыв выполняют после принятия, но до отпускания. Именно здесь обнаруживается зависимость от потерянного FALSE. Третий проверяют после локального отпускания, когда запись ещё могла находиться в очереди.

Затем испытывают закрытие экрана, потерю фокуса, перезапуск панели и перезапуск контроллера. Для удерживаемого действия проверяют прекращение обновлений при каждом сценарии. После восстановления выясняют, какие записи драйвер повторяет и сохраняет ли интерфейс локальное состояние кнопки.

Отдельный тест проверяет потерю подтверждения. Контроллер мог выполнить команду, а HMI не получить ответ. Повторный запрос с тем же идентификатором должен обрабатываться согласно принятой модели, исключая нежелательное повторное действие. Иначе устранение залипания создаст другую проблему: двойной запуск.

Что оставить в документации

Для каждой команды описывают тип: импульсный запрос, желаемое состояние или удерживаемое разрешение. Затем указывают владельца, подтверждение, срок актуальности и реакцию на связь. Это небольшой контракт между HMI и ПЛК, который полезнее устного правила «эта кнопка всегда сама отжимается».

В журнале различают источник запроса, время его принятия, причину отказа и результат. Для удержания не обязательно архивировать каждое обновление в общий журнал оператора, но диагностический след должен позволять понять момент истечения разрешения. Объём регистрации выбирают так, чтобы не перегрузить систему.

При изменении периода обмена повторно проверяют сроки. Ускорение интерфейса или добавление тяжёлого экрана может изменить поведение очереди драйвера. Контракт команд должен выдерживать допустимые задержки проекта, а испытания должны охватывать фактическую сборку HMI и контроллера.

Задержанная запись после восстановления

Потеря связи не обязательно означает немедленное исчезновение всех ожидающих операций. Драйвер может сохранить запись в очереди, повторить её или завершить с ошибкой по собственным правилам. Поэтому при восстановлении важно проверить не только текущее значение бита, но и будущие записи, которые ещё способны прийти. Иначе контроллер сбросит команду, а старая единица появится снова после очередной попытки клиента.

У идентифицируемого запроса можно задать срок допустимости и контекст запуска клиента. Контроллер проверяет, относится ли запрос к текущему сеансу управления. Точный механизм зависит от архитектуры и доступных типов данных. Главное требование состоит в том, чтобы старое намерение нельзя было неявно превратить в новое только из-за восстановления транспорта.

Общий счётчик heartbeat полезен как дополнительная диагностика, но его период и тайм-аут должны быть согласованы с командным протоколом. Если панель обновляет heartbeat другим каналом, он может работать при отказе записи команд. Поэтому положительный heartbeat не отменяет проверку подтверждения конкретного запроса. В испытания включают односторонние и частичные отказы, когда это позволяет стенд.

Реакция интерфейса во время неопределённости

После отправки HMI показывает ожидание подтверждения, а не сразу изображает механизм работающим. Когда подтверждение пришло, отображается принятие, затем фактическое состояние. При потере ответа интерфейс должен показать неопределённость результата. Оператору нужно понимать, что команда могла дойти, а повторное нажатие может быть лишним. Это предотвращает многократные попытки, вызванные одной только задержкой анимации.

Для удерживаемой команды при потере актуального разрешения кнопка становится недоступной до выполнения предусмотренных условий восстановления. При этом нельзя показывать успешный останов только потому, что локально закончился таймер. Физическое состояние приходит от обратной связи или других подтверждённых данных. Командный статус и состояние механизма должны оставаться различимыми даже в аварийном режиме связи.

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

Проверка перезапуска и начальных значений

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

На стенде проверяют перезапуск после приёма команды, но до отправки подтверждения. Затем клиент повторяет запрос по своим правилам. Ожидаемое поведение заранее описывают для конкретного действия: запрет повторения, восстановление статуса или новый запрос после ручного подтверждения. Для необратимых операций неопределённость результата особенно существенна и требует отдельного прикладного решения.

Проверяют и длительное удержание. Если связь периодически пропадает на короткие интервалы, таймер не должен бесконечно продлеваться от старых пакетов без подтверждённого свежего намерения. С другой стороны, допустимые сетевые задержки не должны создавать непрерывное дёргание механизма. Обе стороны компромисса проверяют на фактической частоте обмена и нагрузке проекта.

Результаты включают в таблицу команд вместе с версиями HMI и ПЛК. После изменения обработчиков событий, драйвера или периода опроса повторяют связанные сценарии. Это небольшая, но содержательная проверка: она подтверждает именно устойчивость управления при потерянной паре нажатие–отпускание, которую обычный тест исправной кнопки не охватывает.

При ручной проверке оператор должен видеть подтверждённый режим управления до нажатия. После потери связи прежняя доступность элемента не является доказательством сохранения права управления. Интерфейс обновляет её по актуальному состоянию контроллера, а сам контроллер независимо проверяет запрос. Так поздняя отрисовка или оставшийся открытым экран не превращаются в обход разрешений.

---

Вопросы при работе

Достаточно ли сбрасывать все команды при обрыве общего соединения? Это полезная часть модели, но обнаружение обрыва может запаздывать. Кроме того, соединение может быть живым при устаревшем конкретном запросе. Проверяют фактическое время реакции и свежесть разрешения.

Можно ли сбрасывать бит каждый цикл ПЛК? Для простой одноразовой команды это иногда часть схемы обработки. Но нужно исключить потерю записи, двойное выполнение и неоднозначное подтверждение. Для удерживаемого движения такой сброс сам по себе не описывает намерение оператора.

Можно ли после связи повторить последнюю команду автоматически? Только если это прямо предусмотрено технологической моделью. Для ручного движения обычно требуется новое осознанное действие. Старый сетевой запрос не должен неожиданно оживать после восстановления.

Экранная кнопка «Стоп» решает вопрос безопасности? Нет. Требуемые функции останова и безопасности определяются проектом и реализуются соответствующими средствами. Доступность обычной визуализации нельзя считать гарантированной защитой.

Документация и источники

• Рекомендации PLC–HMI handshake: модели Set/Reset и OnPressed.