Циклическая задача, образ входов и конфигурация модулей

Проект ПЛК описывает не только код. В нём задаются процессор, модули, адреса, параметры каналов, задачи и вызываемые программы. Реальная комплектация должна соответствовать конфигурации. После замены модуля проверяют исполнение, совместимость версии, параметры каналов и диагностику — совпадение внешнего вида не является доказательством эквивалентности.

Для каждого физического канала должна существовать прослеживаемая привязка к переменной. Если программа обращается не к тому адресу, правильная логика обрабатывает чужой сигнал. Поэтому проверка ведомости I/O предшествует сложной отладке алгоритма.

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

Период задачи и время исполнения — разные величины. Если задача вызывается каждые 10 мс и выполняется за 2 мс, это не означает вызов каждые 2 мс. Джиттер характеризует отклонение времени запуска или исполнения по принятому измерению. Контроль времени и watchdog помогают обнаружить выход за установленные ограничения, но не исправляют алгоритм сами по себе.

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

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