Короткий импульс между вызовами задачи ПЛК
Почему R_TRIG пропускает короткий импульс: фильтр DI, обновление входов, период задачи, аппаратная фиксация и испытания ширины и частоты сигнала.
Светодиод входа мигает, осциллограф показывает импульс, а программный счётчик иногда не увеличивается. Детектор фронта уже установлен, но пропуски остались. Если задача ни разу не прочитала единицу, программному детектору нечего распознавать.
Разберём, как импульс проходит входной фильтр, обновление образа и задачу программы. Подключение энкодера и взаимодействие нескольких задач здесь не повторяем. Нас интересует граница между физическим событием и его дискретным наблюдением.
Короткий ответ
R_TRIG обнаруживает переход между состояниями, которые были переданы ему при вызовах. Он не фиксирует самостоятельно импульс, полностью прошедший между наблюдениями. Для надёжного захвата нужно проверить минимальную длительность входа, фильтр модуля, обновление данных и фактический период задачи с джиттером. Если обычный тракт не обеспечивает требуемое наблюдение, используют подходящий аппаратный счётчик, фиксацию события или растяжение сигнала у источника. Способ выбирают по характеристикам конкретного оборудования и частоте событий.
Временной пример
Пусть программа получает вход в моменты 0, 10 и 20 мс. Физический сигнал становится TRUE на 2-й миллисекунде и возвращается в FALSE на 5-й. В моменты наблюдения значение всё время FALSE. R_TRIG корректно сравнивает нули и не выдаёт фронта, хотя трёхмиллисекундный импульс существовал.
Если такой же импульс сдвинуть на интервал 9–12 мс, задача может увидеть TRUE на 10-й миллисекунде. Получается характерная картина: одинаковые по длительности импульсы то учитываются, то пропускаются в зависимости от фазы. Это не случайное решение блока, а следствие дискретизации.
Условный период 10 мс ещё не означает, что максимальный промежуток между реальными наблюдениями равен ровно 10 мс. Добавляются джиттер, задержки обновления I/O и возможные пропуски выполнения. Для гарантии нужен наибольший допустимый интервал в реальной цепочке, а не только поле конфигурации задачи.
С другой стороны, нельзя просто сложить все номинальные времена как независимые задержки и получить точную гарантию. Некоторые процессы синхронизированы, другие работают независимо. Для расчёта используют временную модель оборудования, а затем подтверждают её испытанием при неблагоприятной фазе.
Где импульс может исчезнуть
Первый участок находится в самом датчике. Его выход может иметь ограниченную длительность и время переключения. Настройка импульсного режима, задержка выключения или внутренняя фильтрация влияют на то, какой сигнал реально попадает на клемму. Проверяют паспорт датчика и измерение на допустимой нагрузке.
Второй участок относится к входному модулю. Фильтр может требовать устойчивого состояния в течение заданного времени. Если полезный импульс короче, модуль закономерно не признает его единицей. Уменьшение фильтра требует оценки помех: нельзя улучшить захват полезного события ценой счёта каждого выброса.
Третий участок связан с передачей состояния в контроллер и обновлением образа входов. Физический канал способен переключиться несколько раз между обновлениями образа. Если модуль передаёт только текущее состояние, история этих переключений не появится автоматически в программе.
Четвёртый участок находится в вызове пользовательской логики. Даже обновлённый образ должен быть прочитан нужной задачей, а экземпляр детектора должен вызываться с определённой периодичностью. Условный вызов блока только в некоторых состояниях автомата меняет фактическую последовательность наблюдений.
| Участок | Что выяснить | Как проявляется ограничение |
|---|---|---|
| Выход датчика | Минимальное время ON и OFF | Нет пригодного импульса на клемме |
| Фильтр DI | Условия признания состояния | Короткое переключение отбрасывается |
| Обновление I/O | Период и способ передачи | Между обновлениями остаётся только итог |
| Задача программы | Максимальный интервал наблюдений | Фазовые пропуски |
| Прикладной блок | Частота вызова и память экземпляра | Непредсказуемая обработка истории |
Что умеет R_TRIG
Детектор хранит предыдущее наблюдённое состояние и сравнивает его с текущим. Когда было FALSE, а стало TRUE, выход Q активен в соответствующем выполнении блока. Это программная обработка истории вызовов, а не отдельная аппаратная память входного события.
Экземпляр блока должен сохранять состояние между вызовами согласно правилам среды. Если каждый раз создавать или переинициализировать память, поведение изменится. Также нельзя бездумно вызывать один экземпляр несколько раз за цикл с разными сигналами: его история относится к последовательности этих вызовов.
После захвата фронта приложение может установить собственный флаг события и держать его до обработки медленной задачей. Это полезный приём передачи уже замеченного события. Но флаг не помогает, если первичная задача сама не успела увидеть импульс. Границу аппаратного наблюдения и программного хранения нужно обозначить явно.
Способы сохранить событие
Аппаратная фиксация, или latch, может запомнить краткое переключение до чтения и сброса программой. Поддержка, минимальная длительность и порядок подтверждения зависят от модуля. Если два события приходят до сброса одного флага, простой latch может показать только факт «хотя бы одно», а не количество.
Аппаратный счётчик сохраняет число допустимых фронтов в пределах своих характеристик. Для счёта изделий он часто лучше соответствует задаче, чем булев флаг. Проверяют минимальные времена ON/OFF, максимальную частоту, переполнение, обнуление и согласованное чтение накопленного значения.
Событийная задача или прерывание могут уменьшить задержку реакции, когда оборудование предоставляет подходящее событие. Но они тоже имеют ограничения по частоте и нагрузке. Слишком тяжёлая обработка каждого импульса способна нарушить выполнение остальных задач. Обычно захватывают минимальные данные, а подробную обработку выполняют отдельно.
Растяжение импульса у источника допустимо, если оно не объединяет соседние события. Пусть после растяжения выход остаётся TRUE 30 мс, а изделия дают импульсы каждые 20 мс. Тогда два события могут превратиться в одно длинное состояние. Нужно проверять одновременно минимальную длительность и минимальный промежуток.
Ускорение обычной задачи подходит, когда входной тракт уже способен передать событие и нагрузка контроллера позволяет сократить интервал. Оно не отменяет медленный фильтр DI или редкое обновление удалённого модуля. Изменение периода подтверждают измерением нагрузки и всего маршрута сигнала.
Как провести испытание
Используют подходящий генератор или воспроизводимый источник сигнала с правильными уровнями и нагрузочной способностью. Проверяют электрическую совместимость с входом. Произвольный лабораторный сигнал без учёта общего провода и допустимого напряжения не является корректным тестом промышленного DI.
Сначала подают редкие длинные импульсы и подтверждают правильность адресации и счёта. Затем уменьшают длительность, сохраняя достаточную паузу между импульсами. Отдельно увеличивают частоту. Эти два испытания выявляют разные ограничения: минимальную ширину и способность различать соседние события.
Для проверки фазы задают частоту, не синхронную циклу программы, либо контролируемо сдвигают момент сигнала. Один удачный импульс точно перед чтением не подтверждает гарантированный захват. Фактическое число входных событий сравнивают с независимым счётом источника.
Повторяют тест под допустимой рабочей нагрузкой: с визуализацией, обменом и архивированием проекта. Сохраняют максимальный интервал выполнения задачи и настройки I/O. Если результат зависит от открытого инженерного окна, нужно выяснить причину, а не принимать облегчённый стенд за рабочий режим.
Требования для проекта
В спецификации канала указывают минимальные длительности TRUE и FALSE, максимальную частоту, требуемое количество учитываемых событий и допустимую задержку обработки. Для счётчика отдельно задают диапазон, правила сброса и поведение при перезапуске. Это позволяет выбрать модуль до закупки.
Для сигнала «изделие прошло» требование к количеству отличается от сигнала «обнаружено хотя бы одно событие». Во втором случае защёлка может быть достаточной, в первом нужен счёт или гарантированная обработка каждого импульса. Неопределённость этих требований часто обнаруживается слишком поздно на приёмке.
Фронт и количество являются разными данными
Если аппаратный модуль предоставляет один признак события, программа узнаёт, что переключение было хотя бы один раз после предыдущего сброса. Два или пять переключений могут дать тот же единичный признак. Для диагностики редкого концевика это бывает достаточно, а для учёта изделий нет. Поэтому до выбора latch уточняют, нужно сохранить факт, количество, время первого события или всю последовательность.
При чтении и сбросе защёлки проверяют, что произойдёт с событием между этими операциями. Конкретный модуль может иметь специальное подтверждение, атомарное чтение или другое правило. Простой программный порядок «прочитал, затем записал сброс» нельзя считать безусловно свободным от потери. Руководство должно описывать этот граничный сценарий, а стендовая проверка подтвердить выбранное использование.
Для накопительного счётчика задача программы может читать разность значений за интервал. Тогда частота чтения не обязана совпадать с частотой импульсов, пока соблюдены ограничения счётчика и однозначность переполнения. Но перезапуск, ручной сброс и смена источника требуют отдельного признака. Иначе большое отрицательное изменение ошибочно станет дополнительным выпуском или будет молча отброшено.
Как задать минимальный импульс в ТЗ
Запись «вход до 1 кГц» без длительности уровней недостаточна. У сигнала могут быть несимметричные состояния: короткая единица и длинный ноль. Проверяют минимальные ON и OFF, допустимый коэффициент заполнения и электрические уровни. Для обычного DI также указывают фильтр, а для счётчика способ выбора фронтов. Максимальная частота и минимальная ширина должны относиться к одному разрешённому режиму устройства.
Если источник позволяет изменить длительность импульса, фиксируют диапазон настройки и защищают его от случайной смены. После замены датчика заводское значение может оказаться другим. Тогда программа и модуль останутся прежними, а пропуски появятся снова. Карточка канала должна включать параметры источника, а не только адрес входа и название переменной.
Для удалённого модуля в требования добавляют способ доставки события. Передача текущего состояния через сеть не равна передаче аппаратно накопленного счёта. Если модуль имеет быстрый вход, но драйвер читает только обычный BOOL, преимущество аппаратуры может остаться неиспользованным. Проверяют доступные объекты обмена и фактическую привязку в проекте.
Разбор результатов испытаний
Когда пропуски растут при уменьшении ширины, сравнивают границу с фильтром и временной моделью. Когда они появляются только при увеличении частоты, проверяют паузу между событиями и производительность обработчика. Если проблема зависит от нагрузки визуализации, смотрят фактический интервал задачи. Эти наблюдения помогают выбрать следующую проверку, но не заменяют записи сигнала на входе.
Если генератор выдал тысячу импульсов, а программа показала девятьсот девяносто девять, важно сохранить момент и условия потери. Средний процент успеха не доказывает гарантированный учёт. Для задачи, где каждый пропуск недопустим, даже редкий дефект требует объяснения. Для ориентировочной индикации критерий может быть другим, но его определяют заранее, а не после получения результата.
Отдельно проверяют начало и конец серии. Первый импульс может потеряться из-за инициализации, последний из-за окончания окна регистрации. Счётчик источника и программа должны использовать согласованные границы испытания. Иначе единица расхождения будет ошибочно приписана входному тракту. В протоколе указывают, когда обнулили счётчики, когда разрешили регистрацию и сколько времени ждали завершения последней обработки.
После подтверждения решения сохраняют не только успешный тест, но и пределы: минимальную ширину, максимальную частоту, нагрузку контроллера и настройки фильтра. Это позволяет повторить испытание после замены модуля или обновления проекта. Если один из параметров изменился, прежнее подтверждение нельзя автоматически распространять на новый режим.
При документировании не смешивайте частоту событий и частоту обновления счётчика. Модуль может аппаратно учитывать быстрые импульсы и передавать накопленное число значительно реже. Это допустимо для количества, если определены пределы переполнения и задержки. Для точного времени каждого события нужен другой набор данных. Требование к временному разрешению формулируют отдельно от требования не терять общий счёт, иначе подходящее решение для статистики ошибочно примут за регистратор последовательности.
Вопросы при работе
Если светодиод мигнул, ПЛК обязан увидеть фронт? Нет. Индикация и пользовательская задача могут работать на разных участках цепочки. Нужны характеристики канала и наблюдение данных программы.
Поможет ли TOF после входа? Он может удержать уже прочитанную единицу. Полностью пропущенный между чтениями импульс не запустит программный таймер. Растягивать нужно до участка, который теряет событие.
Нужна ли всегда самая быстрая задача? Нет. Сначала выясняют ограничивающий участок и требования. Аппаратный счётчик нередко решает задачу с меньшей программной нагрузкой.
Можно ли считать короткие импульсы через SCADA? Для гарантированного учёта обычно фиксируют событие или накопленный счёт у источника. Периодический опрос текущего BOOL на верхнем уровне добавляет ещё один участок возможного пропуска.