Инструкция ONS может работать именно так, как задумано, хотя расположенный рядом выход, судя по всему, никогда не активируется. Это кажущееся противоречие объясняется временем сканирования: ONS пропускает переход из ложного состояния в истинное в течение одного сканирования программы, тогда как OTE при каждой проверке строки записывает в назначенный бит текущее условие строки. При последовательном соединении этих инструкций назначенный бит становится истинным на одно сканирование, а затем снова принимает значение «ложь».

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

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

Что на самом деле гарантируют ONS и OTE

Rockwell Automation определяет ONS как инструкцию, которая делает оставшуюся часть строки лестничной логики истинной на протяжении одного сканирования, когда входное условие строки изменяется с ложного на истинное. Её бит хранения запоминает, была ли предшествующая логика уже истинной. Этот бит хранения принадлежит детектору фронта, поэтому не следует бездумно использовать его совместно с другой однократной инструкцией.

У OTE другой принцип работы. Она устанавливает назначенный бит, когда условие строки истинно, и сбрасывает его, когда условие строки ложно. В справочнике битовых инструкций Studio 5000 Rockwell различает однократное включение с помощью ONS и поддерживаемое и сохраняемое поведение инструкций OTE, OTL и OTU.

В сканировании, обнаруживающем фронт, ONS обеспечивает непрерывность строки, и назначенный бит OTE становится истинным. В следующем сканировании вход может всё ещё оставаться истинным, но ONS блокирует прохождение сигнала, поскольку фронт уже был обработан. Затем OTE сбрасывает назначенный бит. Результат — корректный импульс длительностью одно сканирование, а не неисправная катушка.

Почему импульс исчезает из поля зрения

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

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

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

Выбирайте структуру по требуемому поведению состояния

Используйте импульс длительностью одно сканирование для события

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

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

Используйте схему самоподхвата для поддерживаемой энергонезависимой команды

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

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

Однократная инструкция должна запрашивать изменение состояния, а поддерживаемая логика — владеть командой оборудования.

Используйте OTL и OTU только при явно определённом владельце сброса

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

Для сложного оборудования конечный автомат обычно понятнее, чем разрозненные инструкции фиксации и снятия фиксации. Он даёт единое место для определения состояний «Ожидание», «Запуск», «Работа», «Останов» и «Авария», а также допустимых переходов между ними.

Последовательность поиска неисправности от наиболее вероятной причины

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

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

Далее выполните перекрёстную проверку назначения OTE. Другая OTE, OTL, OTU, производимый тег, псевдоним или внешняя запись могут изменить тот же бит позже в сканировании или в другой задаче. В документации Rockwell для OTE отдельно предупреждается о возможности перезаписи операндов. Назначьте одного владельца итоговой команды, а другим процедурам позвольте запрашивать изменения через отдельные теги.

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

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

Пример применения: выбор ведущего насоса

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

По обратной связи состояние должно перейти из «Запуск» в «Работа», а превышение времени запуска должно сформировать реакцию на неисправность. Запрос останова и неисправности должны переводить состояние к управляемому останову или немедленному отключению в соответствии с проектом процесса. Такое разделение не позволяет кратковременному событию выбора стать единственным условием удержания команды двигателя.

Ещё один пример преобразования логического замысла в поддерживаемую структуру лестничной логики приведён в исправленном руководстве по XOR для трёх переключателей и логике нечётной чётности. Варианты контроллеров и ввода-вывода также можно изучить в разделе систем ПЛК и PAC.

Проверка конструкции — это определение владельца

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

Часто задаваемые вопросы

Активирует ли ONS следующую за ней OTE?

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

Почему я не вижу включения OTE в онлайн-режиме?

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

Следует ли заменить OTE на OTL?

Только если действительно требуется сохраняемое состояние и все условия снятия фиксации явно спроектированы. Для многих команд оборудования конечный автомат или схема самоподхвата с одним владельцем OTE проще для аудита.

Могут ли две инструкции ONS использовать один и тот же бит хранения?

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

Может ли OTE длительностью одно сканирование управлять физическим выходом?

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