Условный вызов таймера TON в программе ПЛК

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

Разберём обычный TON, жизненный цикл экземпляра и проверку переходов автомата. Аппаратный watchdog и захват короткого импульса здесь не рассматриваем. Главный вопрос состоит в том, когда блок действительно получает новые входные условия и когда обновляются его выходы.

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

Вызов TON с IN = FALSE и отсутствие вызова являются разными операциями. Для сброса по обычной модели таймер должен быть выполнен с соответствующим входом. При пропуске вызова нельзя предполагать универсальное замораживание внутреннего времени: детали зависят от реализации. Надёжнее вызывать экземпляр в определённом месте каждого цикла и передавать условие через IN. Поведение после перезапуска и изменения PT проверяют для применяемой библиотеки и runtime.

Вызов и состояние экземпляра

Функциональный блок хранит данные между выполнениями. У TON это позволяет связать текущий вызов с началом отсчёта и входными переходами. Если программа не вызывает блок, она не выполняет его обычную логику в этот момент. Значение Q в памяти может оставаться от предыдущего выполнения.

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

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

Экземпляр должен быть определённым и сохранять нужное состояние. Если его память создаётся заново или неправильно инициализируется, наблюдаемое поведение тоже изменится. В сложном проекте сначала находят объявление и все места вызова, а уже затем обсуждают значения IN и PT.

Пример двух подходов

Первый фрагмент показывает распространённую ловушку. Когда StepActive становится FALSE, блок не вызывается. Последующее чтение Delay.Q использует состояние, которое не было обновлено этим циклом. В примере нет обещания конкретного значения после возврата: именно оно требует проверки реализации.

IF StepActive THEN
    Delay(IN := TRUE, PT := T#2s);
END_IF;

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

Delay(IN := StepActive, PT := T#2s);
StepTimedOut := Delay.Q;

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

Порядок в цикле

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

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

В FBD и LD дополнительно проверяют правила выполнения сети и входы разрешения. Визуально расположенный блок не обязательно выполняется так, как предполагает автор ST-примера. Нужно учитывать конкретную среду и сгенерированную последовательность. Онлайн-подсветка помогает, но не заменяет понимание условий выполнения.

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

Изменение PT во время отсчёта

Операторская уставка выдержки может измениться, пока IN уже TRUE. Тогда нужно знать, как библиотека трактует новое PT. Нельзя считать, что каждый таймер запоминает PT только на старте или, наоборот, всегда немедленно применяет изменение. Поведение подтверждают документацией и тестом.

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

Ввод уставки проверяют по диапазону и единице. Секунды на экране и миллисекунды в программе легко перепутать. Преобразование в TIME должно учитывать доступный диапазон типа и поведение при выходе за него. Красивое поле ввода не защищает от переполнения промежуточного целого.

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

Перезапуск и сохранение

Ретентность экземпляра не следует включать автоматически ради продолжения отсчёта. Внутренние временные отметки могут иметь смысл только в определённом контексте runtime. Сохранение памяти не равно корректному учёту времени выключенного контроллера. Требование продолжать операцию после питания нужно описать отдельно.

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

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

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

Стендовая трасса

Записывают IN, PT, Q, ET и состояние шага с достаточным временным разрешением. Для проверки пропуска вызова полезно добавить диагностический счётчик выполнений рядом с вызовом. Тогда видно, получал ли блок FALSE или просто не исполнялся. Один просмотр текущего значения после остановки не показывает историю.

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

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

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

Что оставить следующему разработчику

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

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

Выдержка шага и срок всей операции

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

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

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

Проверка границы срабатывания

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

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

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

Контроль после онлайн-изменения

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

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

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

---

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

Не вызывать TON означает заморозить время? Это нельзя считать универсальным правилом. Выходы не выполняются в пропущенном месте, а внутренний расчёт при следующем вызове зависит от реализации.

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

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

Почему Q меняется на цикл позже? Проверьте порядок чтения и вызова, а также момент вычисления состояния шага. Затем сопоставьте это с фактическим периодом задачи.

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

• CODESYS Standard: TON.