Логика самоподхвата или OTL/OTU? Безопасный выбор памяти ПЛК
Схемы самоподхвата и инструкции OTL/OTU могут удерживать одну и ту же команду, но при сбое ведут себя по-разному. В этом руководстве сравниваются поведение при сканировании, риск при перезапуске, п...
Команду двигателя, которая остаётся активной после того, как оператор отпускает кнопку запуска, можно реализовать с помощью ветви самоподхвата или инструкций с фиксацией и сбросом. Установившийся результат на HMI может выглядеть одинаково. Однако поведение при отказе различается — и эта разница важна во время перезапуска, неисправности или онлайн-редактирования.
Поэтому полезный инженерный вопрос звучит не так: «Какая инструкция лучше?» Вопрос в другом: «Где должно храниться состояние, кто имеет право его изменять и какие условия должны сохранять приоритет?»
Два способа запоминания — два разных принципа работы
В обычной строке с самоподхватом используется стандартная инструкция выхода и параллельный контакт управляемого бита. В терминологии Logix инструкция Output Energize отслеживает состояние строки в каждом цикле: истинная строка записывает в бит значение true, а ложная — false. Ветвь сохраняет истинность строки после исчезновения кратковременного запроса запуска, но последовательно установленные условия останова, неисправности или разрешения могут немедленно разорвать цепь.
Инструкция Output Latch записывает в бит значение true, когда строка становится истинной. После этого бит остаётся истинным, пока инструкция Output Unlatch — или другой источник записи — не очистит его. В справочнике инструкций для работы с битами Rockwell Automation OTE описывается как выход, отслеживающий состояние строки, а OTL и OTU — как ретентивные операции установки и сброса.
Пара установки и сброса разделяет условия формирования и снятия команды. Диаграмма сохранена из исходной иллюстрации; источник: Control.com.
Цикл сканирования определяет, какому варианту проще доверять
Логика самоподхвата делает приоритетную цепь останова очевидной
Для простого запроса на запуск схема с самоподхватом сохраняет условия запуска, останова, перегрузки, режима и разрешения видимыми в одной строке. Когда любое последовательно установленное условие становится ложным, OTE записывает значение false в этом же цикле. Технический персонал обычно может проследить всё решение без поиска по нескольким подпрограммам.
Схема усложняется, когда запускать или останавливать одно и то же состояние могут многие подсистемы. Бесконечное добавление параллельных ветвей скрывает приоритеты и затрудняет онлайн-поиск неисправностей. В такой ситуации отдельная машина состояний часто понятнее, чем огромная строка с самоподхватом или разрозненные инструкции фиксации.
OTL и OTU разделяют события и состояние
Ретентивные инструкции полезны, когда независимые события должны устанавливать и сбрасывать состояние: шаг последовательности, завершённое рукопожатие, подтверждение аварии или запрос, который должен пережить импульс запуска. Риск связан с владением состоянием. Если один и тот же тег записывается из нескольких подпрограмм, итоговое значение может определяться порядком задач и циклов сканирования.
Перекрёстная ссылка, показывающая одну инструкцию фиксации и одну инструкцию сброса, сама по себе не доказывает безопасность поведения. В программе также должно быть явно определено правило приоритета. Если условия установки и сброса могут быть истинными в одном цикле, инженер должен задокументировать, какой результат имеет приоритет, и убедиться, что расписание выполнения подпрограмм не может неожиданно изменить его.
Храните запоминаемое состояние отдельно от физического выхода
Хороший подход — сохранять внутреннюю команду или состояние последовательности, а затем управлять физическим выходом с помощью одной инструкции OTE, разрешаемой текущими условиями. Сохранённый запрос может оставаться истинным, но команда исполнительному механизму всё равно снимается, когда перегрузка, защитное ограждение, технологическая блокировка или рабочий режим отменяет разрешение.
Такое разделение также улучшает диагностику. Операторы могут видеть, что запрос на запуск существует, но конкретное разрешение блокирует движение. Тот же принцип полезен при вводе контроллера в эксплуатацию; в процедуре ввода Micro800 в эксплуатацию объясняется, почему выходы следует проверять в контролируемых условиях, а не делать выводы только по внутреннему биту.
Функции безопасности требуют оборудования с соответствующим уровнем безопасности, проверенной логики и документированного проекта снижения риска. Ни ветвь самоподхвата, ни обычная пара OTL/OTU не превращает стандартный выход ПЛК в функцию безопасности.
Поведение при перезапуске — это требование проекта, а не неожиданность
Перед выбором ретентивной логики определите, что должно происходить после отключения питания, смены режима контроллера, загрузки программы или прерывания связи. Физический контактор обесточится при исчезновении питания, но сохраняемая команда может остаться истинной после возобновления управления. Автоматический перезапуск может быть допустимым для некоторых непрерывных процессов и недопустимым для оборудования, доступного персоналу.
Используйте состояние запуска, которое намеренно сопоставляет сохранённые запросы с текущими полевыми условиями. Проверьте устройства обратной связи, очистите устаревшие сигналы рукопожатия, восстановите требуемое качество связи и потребуйте нового действия оператора там, где это предусмотрено оценкой риска.
Проверки при вводе в эксплуатацию, выявляющие скрытые дефекты
Проверяйте не только запуск и останов. Удерживайте оба запроса истинными, поочерёдно снимайте каждое разрешение, вызывайте неисправность во время перехода между состояниями, переключайте режимы контроллера, прерывайте сетевую обратную связь и проверяйте поведение после восстановления питания. Одновременно отслеживайте бит команды, итоговую строку управления выходом и полевую обратную связь.
Одноимпульсное поведение также может изменить схему с фиксацией. Если ожидается только одно событие, проверьте бит хранения и время сканирования. В связанном руководстве о одноимпульсных сигналах Studio 5000 и поведении OTE показано, почему импульс, существующий внутри программы, может так и не привести к ожидаемому результату на поле.
Редакционная позиция: единое владение важнее предпочтения инструкции
Для простых команд с поддержанием состояния PLC ProTech рекомендует схему с самоподхватом, поскольку цепь останова видима и постоянно оценивается. Для состояний последовательности и хранения событий подходит логика установки и сброса, если одна подпрограмма владеет состоянием, приоритет сброса определён явно, а физический выход управляется отдельной инструкцией OTE, разрешаемой текущими условиями.
Выбор инструкции вторичен. Решающий показатель качества — может ли другой инженер определить всех записывающих в состояние, предсказать состояние после прерывания и доказать, что защитные условия имеют приоритет.
Часто задаваемые вопросы
Оставляет ли инструкция OTL настоящий выход включённым при отказе питания?
Нет. Потеря управляющего питания обесточивает физическую цепь выхода. Проблема в том, что сохраняемый бит команды может остаться истинным после возврата контроллера и системы выходов, в зависимости от контроллера, настроек памяти и логики запуска.
Является ли строка с самоподхватом неретентивной?
OTE отслеживает состояние строки при каждом её сканировании. Ветвь самоподхвата может поддерживать истинность строки в нормальном режиме, однако поведение при запуске и предварительном сканировании зависит от контроллера. Инженерам следует проверять целевую платформу, а не предполагать одинаковое поведение у разных семейств ПЛК.
Можно ли использовать один и тот же тег в инструкциях OTL, OTU и OTE?
Многие ПЛК допускают несколько источников записи, но результат может зависеть от порядка выполнения и быть трудным для диагностики. Более безопасная конструкция назначает каждому состоянию одного владельца и управляет каждым физическим выходом из одного итогового места.
Когда логика установки и сброса является лучшим выбором?
Она полезна для хранения событий, шагов последовательности, подтверждения аварий и рукопожатий, которые должны сохраняться дольше одного цикла сканирования. Условие сброса, политика запуска и реакция на неисправность должны определяться одновременно.