После кратковременного просадки 24 В или «зависания» загрузки CPU индикатор ПЛК горит STOP, в CODESYS Online - та же картина. Наладчик жмёт Run, контроллер дёргается и снова STOP. В диагностике - watchdog timeout, exception в задаче, иногда пустой стек. Оператор спрашивает, когда запустят линию. Вы смотрите на насосы в ручном и понимаете: пока не ясна причина, RUN опасен.
Watchdog на ПЛК - не «глюк железа», а штатная защита: если цикл задачи не завершился вовремя или runtime упал, контроллер переводит себя в безопасное состояние STOP. Повторный RUN без устранения причины снова упрётся в тот же таймаут или в аварийную логику пуска. Статья разбирает цепочку watchdog - задачи - питание - cold start и отличие от потери retain и уставок. Это не учебник по языкам ST/FBD - только эксплуатационная диагностика и безопасный порядок действий.
Если ПЛК остаётся в STOP после watchdog и не переходит в RUN, сначала прочитайте журнал исключений и время цикла задач, не жмите Run на живом объекте вслепую. Типичные причины: превышение watchdog interval тяжёлой задачей, блокирующий вызов в цикле, скачок нагрузки после download, нехватка питания 24 В, повреждённый проект на flash. Безопасный порядок: зафиксировать STOP и outputs, снять online-лог, воспроизвести на столе или в симуляции, исправить задачу или увеличить interval обоснованно, cold start по регламенту с проверкой interlocks. Retain и уставки могут сохраниться - watchdog не равен «обнулились все уставки». Таблица ниже сопоставляет состояние, причину и действие.
Watchdog (сторожевой таймер) следит, что пользовательские задачи завершают цикл за отведённое время. В CODESYS задача имеет interval (период) и watchdog margin. Если тело задачи выполняется дольше допустимого - runtime фиксирует fault и переводит ПЛК в STOP. Аналогичная логика есть в других средах на том же классе железа.
STOP после watchdog - следствие, не первопричина. Первопричина - код или конфигурация, из-за которых цикл «не уложился», либо сбой питания/памяти, из-за которого runtime не стартовал корректно. Индикатор STOP с записью watchdog в логе отличается от STOP по команде оператора и от STOP из-за аппаратной ошибки I/O.
Важно: выходы при переходе в STOP обычно переходят в безопасное состояние по конфигурации (часто 0 или last value по таблице - смотрите проект и паспорт объекта). Повторный RUN без анализа может кратковременно подать команду на исполнительный механизм.
Частая история на пуске: добавили в задачу 10 ms новый FB с файловой записью, разбором строки или большим циклом FOR по массиву. На столе с одним ПЛК всё OK, на объекте с полной нагрузкой Modbus и архивом - watchdog.
Вторая история - вызов блокирующих операций в цикле: синхронный запрос к медленному устройству, ожидание без таймаута, WHILE без выхода при ошибке датчика. Язык (ST, FBD, LD) не спасает - важно, что выполняется за один scan. Обзор языков и типичных ловушек по средам - в материале про ST, FBD, LD, здесь только runtime-поведение.
Третья - приоритеты задач: низкоприоритетная задача «съела» время, высокоприоритетная не стартовала вовремя. Смотрите task configuration, загрузку CPU % в online, trace если доступен.
Диагностика: в online откройте task monitoring - max cycle time, overrun counter. Сравните до и после инцидента. Если max cycle скачкообразно вырос - ищите последний download или изменение рецепта.
Просадка питания короче секунды может не выключить индикаторы на шкафу, но сбросить CPU в fault. Блок питания на грани нагрузки, плохой контакт на клемме, пуск мощного насоса в той же фазе - типичные полевые причины.
Отличие от watchdog по коду: в логе может быть power fail, reset reason hardware, без exception в задаче пользователя. Осциллограф на 24 В или журнал UPS помогает. Если STOP совпадает с пуском соседнего агрегата - электрика, не программист.
После brownout иногда требуется не Run, а power cycle с проверкой целостности проекта на flash. Повторяющиеся события - замена БП, увеличение запаса по току, отдельная линия для ПЛК.
Первое действие наладчика - снять online log, last error, call stack если среда показывает. Сохраните скрин и экспорт до перезагрузки. Сообщение division by zero, access out of range, stack overflow указывает на конкретный POUs.
Cold start (холодный пуск) - перезапуск runtime с инициализацией переменных по INIT, если так настроено. Warm start / retain сохраняет часть памяти. Watchdog STOP не означает автоматически потерю retain - смотрите настройки retain list и что именно пропало на объекте. Оператор мог заметить «слетели уставки» по другой причине (загрузили старый проект).
Если Run сразу снова watchdog - не крутите цикл бесконечно. Переведите объект в безопасное состояние, отключите проблемную задачу в проекте на столе, выпустите патч. Временное увеличение watchdog interval без анализа - маскировка, не ремонт.
Иногда STOP сопровождается записью memory fault или corruption project. Тогда Run бесполезен до восстановления проекта из backup. Не путайте с чистым watchdog по времени цикла - в логе будет другой код.
При работе с удалённым I/O по Ethernet потеря связи с модулем может блокировать transition в Run по логике проекта, хотя CPU физически готов. Диагностика - диагностика полевой шины и конфигурации I/O, не только watchdog margin.
Работать от риска механизмов. Убедитесь, что клапаны, приводы, ПЧ в безопасном состоянии, технолог подтвердил обход или ручной режим. Зафиксируйте, какие выходы должны оставаться обесточенными.
Снимите логи и конфигурацию as-built. Воспроизведите на bench ПЛК с копией проекта и тем же firmware. Если fault воспроизводится - правка кода. Если нет - питание, помехи, повреждение flash, несовместимость версии после обновления.
Перед Run на объекте: проверьте interlocks, что аварийные цепи целы, персонал вне зоны. Первый Run - с технологом, готовностью к немедленному STOP. После устойчивого RUN 15-30 минут - запись в журнал пусконаладки: причина, меры, версия проекта.
Документируйте в пакете ввода: максимальное время цикла, настройки watchdog, процедура после fault. Ссылка на общий маршрут инженера - путеводитель по ресурсам АСУ ТП.
После загрузки проекта без остановки объекта иногда меняется порядок инициализации: тяжёлый INIT в первом цикле не укладывается в watchdog. Симптом - STOP только на первом Run после download, на втором (если успели нажать) - то же. Решение - вынести длительную инициализацию в отдельную фазу, разбить на несколько циклов, увеличить watchdog только для стартовой задачи с комментарием в проекте.
Retain-переменные не защищают от watchdog. Можно сохранить уставки и одновременно оставаться в STOP. Операторы путают: «уставки на месте, значит можно жать Run». Если причина - exception в коде, уставки ни при чём.
Сравните версию компилятора и runtime на столе и на объекте. Расхождение patch-level иногда даёт разное время выполнения библиотечных FB.
На объекте с десятками Modbus TCP устройств цикл опроса может блокировать задачу, если драйвер синхронный и один slave не отвечает до timeout. Watchdog падает «случайно» при отказе одного прибора. Диагностика - временно отключить устройство в конфигурации, повторить Run. Долгосрочно - асинхронный опрос, отдельная comm-задача, сокращение timeout на неответ.
Архивирование на самом ПЛК (файл на flash, FTP) в цикле 10 ms - классическая ошибка. Выносите на медленную задачу или на верхний уровень.
В CODESYS 3.5 откройте Task Configuration: period, priority, watchdog enable, watchdog time. Для каждой задачи - max cycle time в online. Если watchdog time = period - margin слишком мал, любой всплеск CPU даёт STOP.
Функциональные блоки с циклическим вызовом в нескольких задачах без защиты - риск гонки и непредсказуемого времени. Это уже не только watchdog, но и источник «плавающих» overrun.
| Ситуация | Признак | Не путать с |
|---|---|---|
| Watchdog timeout | Запись в логе, overrun cycle | STOP по кнопке; аварийный вход |
| Потеря retain | Уставки сброшены, RUN возможен | Watchdog не обязан стирать retain |
| Ошибка I/O модуля | Диагностика модуля, не task overrun | Чистый watchdog по времени |
| Нет transition в Run | Запрет из логики `AllowRun=FALSE` | Hardware fault |
| После download | Первый старт падает | Старая версия на flash |
| Состояние | Вероятная причина | Безопасное действие |
|---|---|---|
| STOP, watchdog в логе, overrun растёт | Тяжёлая задача, блокирующий код | Не Run на объекте; trace; правка задачи; обоснованный interval |
| STOP сразу после Run | Exception в первом цикле INIT | Call stack; отключить новый FB; симуляция |
| STOP после просадки 24 В | Brownout, БП | Осциллограф; БП; клеммы; не только софт |
| STOP после обновления firmware | Несовместимость проекта | Откат версии; миграция по инструкции вендора |
| Run на секунду, снова STOP | Периодический пик нагрузки | Разнести задачи; оптимизировать Modbus опрос |
| STOP только на объекте, на столе OK | Питание, помехи, полная конфигурация I/O | Сравнить hardware config; журнал питания |
| Лог пустой, STOP горит | Аппаратный fault CPU | Техподдержка; замена; не циклить Run |
| Оператор жмёт Run подряд | Человеческий фактор | Блокировка до анализа; регламент |
После исправления зафиксируйте max cycle time в паспорте задачи. При следующем расширении проекта сравните с baseline - перегруз CPU нарастает незаметно, пока не сработает watchdog в жару или при пиковой нагрузке линии.
Журнал событий на встроенном экране ПЛК или в SCADA сохраняйте при каждом watchdog STOP. Без истории на пуске через месяц спорят, было ли это «в первый раз» или хроническая перегрузка цикла.
Можно ли увеличить watchdog до 1 с «чтобы не падало»?
Только с расчётом worst-case cycle time и согласованием с функциональной безопасностью. Иначе вы теряете смысл защиты и маскируете перегрузку CPU.
Сбросятся ли уставки после watchdog?
Зависит от retain и того, был ли cold reset. Watchdog сам по себе не равен потере уставок. Проверьте фактические значения в online до и после.
Кто может давать Run на объекте?
Только уполномоченный персонал по наряду/регламенту, с подтверждением технолога. Кнопка Run в CODESYS - не игрушка на живом насосе.
Нужно ли менять проект после каждого watchdog?
Нет, если причина - разовый brownout. Если причина - код, без патча повторится.
ПЛК СТАБУР под CODESYS 3.5 или MasterSCADA 4D на одном железе дают online-диагностику задач и журнал на встроенном экране или по Ethernet. Имеет смысл заранее включить логирование overrun и хранить as-built проекта на microSD - восстановление после fault быстрее, чем поиск «финальной версии» на ноутбуке подрядчика.