На модуле дискретного ввода горит светодиод нужного канала. Кажется, что полевой сигнал уже дошел до контроллера и дальше остается только найти его в программе. Но в watch-окне переменная остается FALSE, на HMI индикатор не меняется, а логика продолжает считать датчик неактивным.
Такое расхождение редко устраняется одним взглядом на строку кода. Между LED и экраном оператора есть несколько слоев: входная электроника, конфигурация модуля, образ процесса, адрес, привязка переменной, промежуточное копирование, задача программы и отдельный тег HMI. Состояние нужно проследить по этой цепочке и найти первую точку, где TRUE перестает быть виден.
Короткий ответ
Горящий LED подтверждает только состояние индикации физического канала по правилам конкретного модуля. Сначала посмотрите диагностическое или онлайн-состояние самого канала в конфигураторе оборудования. Если канал там активен, переходите к его адресу в образе входов, затем к напрямую привязанной переменной, внутреннему тегу и месту использования в задаче.
На каждом шаге сравнивайте два соседних уровня одновременно. Если аппаратный канал меняется, а адрес нет, причина находится в конфигурации или отображении I/O. Если адрес меняется, а переменная нет, проверяйте привязку и тип. Если входная переменная живая, а рабочий тег замер, ищите инверсию, копирование, force, симуляцию, фильтр или задачу, которая не выполняется.
LED не равен переменной программы
Светодиод на модуле полезен как первая контрольная точка, но его смысл нужно брать из руководства. В одном модуле LED показывает электрический уровень на входной цепи, в другом - состояние после внутренней обработки. Индикация может продолжать работать при диагностической ошибке канала или при отсутствии корректного обмена модуля с CPU.
Поэтому вывод «провод и датчик исправны» только по LED слишком широкий. Индикация подтверждает, что конкретный аппаратный узел увидел состояние, но еще не доказывает, что оно попало в образ процесса текущей конфигурации контроллера.
Базовое различие физических дискретных и аналоговых каналов разобрано в материале «Дискретные и аналоговые сигналы в АСУ ТП». Для текущей диагностики важен практический вывод: состояние физического канала и переменная программы связаны конфигурацией, а не названием тега.
Начать с точной идентификации канала
Перед подключением к ПЛК стоит зафиксировать:
•обозначение модуля и его позицию в корзине или удаленной станции;
•номер канала возле активного LED;
•обозначение сигнала по схеме;
•клемму и адрес из карты I/O;
•имя ожидаемой переменной;
•версию проекта, загруженную в контроллер.
Ошибка на один канал встречается чаще, чем кажется. Нумерация на корпусе может начинаться с нуля, а в таблице проекта - с единицы. Каналы соседних групп могут иметь похожую индикацию. При удаленном I/O добавляется адрес станции и слота. Фотография модуля с отмеченным LED и ссылка на лист схемы экономят время при разборе.
Актуальная КД для АСУ ТП должна провести сигнал от полевого устройства через клемму до позиции модуля и программного обозначения. Если эти данные расходятся, сначала фиксируют расхождение, а не выбирают адрес по догадке.
Проверить состояние канала в конфигурации оборудования
Следующая точка находится не в пользовательской логике, а в диагностике модуля. Онлайн-представление оборудования обычно позволяет увидеть состояние канала, статус модуля и ошибки обмена. Названия окон отличаются в разных IDE, но смысл проверки один: видит ли CPU тот же бит, который показывает LED?
Если LED горит, а онлайн-состояние аппаратного канала не меняется, проверяют:
•соответствует ли реальный модуль конфигурации проекта;
•совпадают ли позиция, тип и ревизия модуля;
•находится ли модуль в рабочем состоянии;
•нет ли ошибки удаленной станции или шины;
•включен ли канал и выбран ли ожидаемый режим;
•загружена ли текущая аппаратная конфигурация.
На этом этапе еще не нужно редактировать программу. Если состояние потерялось до образа входов, изменение логического условия только замаскирует источник расхождения.
Адрес и карта I/O
Когда диагностика модуля показывает активный канал, находят его фактический адрес. Для дискретного входа это может быть бит в байте образа процесса, символическое отображение канала или поле структуры устройства. Важно проверить адрес в онлайн-конфигурации, а не только в офлайн-таблице проекта.
Смещение модуля могло измениться после добавления нового оборудования, замены типа карты или перестройки удаленной станции. Старый адрес при этом остается в переменной и продолжает быть синтаксически допустимым, но указывает на другой бит. Особенно коварен случай, когда соседний адрес тоже иногда меняется: программа выглядит живой, хотя читает другой датчик.
Полезно наблюдать одновременно диагностический бит канала и сырой адрес образа входов. Если они меняются вместе, аппаратный слой и отображение I/O работают. Если нет, граница проблемы уже определена.
Привязка переменной
Следующий слой - переменная, непосредственно связанная с входом. Здесь проверяют не ее красивое имя, а объявление и фактическую привязку. Возможные ошибки:
•указан соседний адрес;
•переменная связана с другой станцией или экземпляром устройства;
•тип не соответствует представлению канала;
•символическая привязка потерялась после изменения конфигурации;
•одно имя существует в разных областях видимости;
•HMI и программа смотрят на разные экземпляры структуры.
Наблюдайте сырой вход и привязанную переменную в одном онлайн-окне. Если адрес меняется, а переменная нет, искать нужно в объявлении, отображении и области видимости. Переименование тега без проверки привязки не решает проблему.
Инверсия и смысл активного состояния
Физический вход может быть активен уровнем 1, но рабочая переменная намеренно инвертируется. Так часто обрабатывают нормально замкнутые контакты, сигналы готовности или аварийные цепи. Например, сырой тег DI_GuardClosed равен TRUE, а внутренний GuardOpen вычисляется через NOT.
Проблема возникает, когда инверсия выполнена дважды либо название уже подразумевает отрицательный смысл. Тогда LED горит, входная переменная меняется, но наблюдаемое условие выглядит противоположно ожиданию. Нужно выписать выражение целиком и сопоставить его с электрическим состоянием контакта по схеме.
Копирование во внутренний тег
Во многих проектах аппаратные входы не используются напрямую. В начале цикла их копируют в структуру, нормализуют имена, применяют маски, диагностику и разрешения. Логика и HMI затем работают с внутренним тегом.
Пример цепочки может выглядеть так:
аппаратный бит -> DI_Raw -> DI_Normalized -> Equipment.Status -> HMI tag
Если DI_Raw меняется, а следующий тег нет, найдите все места записи во внутреннюю переменную. Она может присваиваться только при условии, перезаписываться позже в цикле или обновляться в другой задаче. Поиск всех ссылок на запись обычно полезнее чтения одного фрагмента программы.
Особенно внимательно проверяют конструкции, где структура целиком копируется после обработки отдельных полей. Позднее присваивание старого экземпляра способно вернуть бит в прежнее состояние в том же цикле.
Симуляция и force
Режим симуляции может намеренно подменять физические входы тестовыми значениями. Иногда переключатель симуляции находится в глобальной переменной, сервисном экране или конфигурации конкретного механизма. LED при этом честно показывает поле, а программа сознательно использует виртуальный источник.
Force действует еще прямее: переменная удерживается в заданном состоянии независимо от аппаратного входа. В разных средах принудительное значение может применяться к адресу, символу или внутреннему тегу. Поэтому проверяют общий список активных force, а не только значок рядом с открытой переменной.
Снятие force и изменение online-проекта выполняют только по принятому на объекте порядку. Материал об анализе отказов оборудования и рисках онлайн-отладки ПЛК полезен именно как напоминание: возможность менять состояние без остановки не отменяет оценки влияния на действующий процесс.
Фильтр входа и короткий импульс
Аппаратный или программный фильтр подавляет импульсы короче установленного времени. LED может успеть вспыхнуть, а отфильтрованное состояние не попадет в образ процесса либо не сохранится до выполнения задачи. Обратная ситуация возникает при большой задержке отпускания: физический сигнал уже исчез, а переменная еще остается активной.
Для проверки нужен временной контекст. Сравните длительность сигнала, настройку фильтра, период обновления модуля и цикл задачи. Если вход меняется только на коротких импульсах, одиночное наблюдение в watch-окне ненадежно. Используют трассировку, счетчик фронтов или журнал с достаточным разрешением, не меняя фильтр вслепую.
Задача программы и порядок выполнения
Переменная может быть объявлена правильно, но код, который ее копирует или обрабатывает, не выполняется. Причины: программа не назначена задаче, задача остановлена, условный вызов не проходит, экземпляр функционального блока не вызывается либо используется другой экземпляр.
Проверьте статус задачи, период выполнения и счетчик циклов. Поставьте наблюдаемую контрольную переменную в том же программном блоке или используйте штатную трассировку выполнения. Если задача работает, смотрите порядок присваиваний внутри цикла. Значение может кратко стать TRUE, а затем быть перезаписано до обновления watch-окна.
Отдельный риск - слишком медленная задача для короткого сигнала. Физический канал и быстрый образ входов замечают импульс, но пользовательская задача запускается после его окончания. Тогда решением может быть предусмотренная архитектурой фиксация фронта или более подходящая задача, а не увеличение случайных задержек.
HMI как отдельный последний слой
Если переменная в ПЛК меняется, а HMI молчит, аппаратный вход уже оправдан. Дальше проверяют тег визуализации, источник данных, качество связи, период опроса, инверсию анимации и экземпляр объекта. На экране может использоваться внутренний статус механизма, а инженер ожидает увидеть сырой вход.
Сравните имя и полный путь тега в HMI с онлайн-переменной ПЛК. Проверьте качество и временную метку. Если связь обновляет другие теги, а один бит замер, вероятнее ошибка привязки или кэширования конкретного элемента, чем неисправность входного модуля.
Таблица последовательной проверки
Что зафиксировать после обнаружения
В результате диагностики должна остаться короткая воспроизводимая цепочка: какой LED был активен, где состояние еще наблюдалось и на каком переходе исчезло. Приложите адрес, имя переменной, экземпляр программы, задачу, снимок онлайн-значений и ссылку на лист карты I/O.
Если обнаружена временная симуляция, force или обходное копирование, запишите владельца, причину и порядок возврата. Если адрес проекта не совпадает с реальным каналом, обновляют не только код, но и карту I/O, КД и as-built по принятому процессу.
Частые вопросы
Может ли LED гореть при неисправном обмене модуля с CPU?
Да, если индикация формируется локальной электроникой модуля. Поэтому после LED обязательно проверяют статус модуля и онлайн-состояние канала со стороны контроллера.
Почему watch-окно не показывает короткий импульс?
Его обновление обычно медленнее цикла ПЛК. Импульс может пройти между двумя обновлениями экрана. Для проверки используют трассировку, счетчик фронтов или диагностический буфер.
Можно ли временно привязать другую переменную к адресу?
На действующем объекте такое изменение оценивают как вмешательство в программу. Безопаснее сначала наблюдать сырой адрес и существующие привязки, не создавая дополнительную запись или force.
Почему переменная меняется в ПЛК, но не на HMI?
Чаще всего HMI смотрит на другой тег, экземпляр или внутренний статус. Также проверяют качество связи, период опроса, инверсию анимации и кэширование.
С чего начинать: со схемы или с IDE?
С короткой сверки физического канала по схеме, затем переходить в онлайн-диагностику. Без точного номера модуля и канала легко убедительно отлаживать соседний вход.
Обсуждение