Распределённые часы EtherCAT и задача ПЛК: джиттер, которого нет в тренде SCADA
Distributed Clocks EtherCAT не лечат джиттер задачи IEC. Почему тренд SCADA 1 с слепой и чем мерить ось: DC, монитор цикла, scope привода.
На линии с тремя сервоосями и десятком пневмоклапанов смена сдала смену с формулировкой «иногда дёргает». В SCADA тренд положения с периодом 1 с гладкий. Следующий ход - ошибка следования, привод в Fault, оператор клянётся, что «график ровный». Наладчик открывает монитор задачи ПЛК: период 1 мс, максимум цикла 2,4 мс, джиттер сотни микросекунд. На шине EtherCAT распределённые часы вроде синхронизированы. Два разных времени живут в одном шкафу, а историк видит третье - секундное.
Разбираем стык Distributed Clocks и циклической задачи IEC на одном контроллере, когда motion и процесс делят CPU: почему DC не лечит сорванный цикл, почему тренд SCADA не ловит микросекунды, чем мерить на оси и на клапане. Здесь нет выбора полевой шины «EtherCAT или Profinet» - это соседний разбор. Нет и NTP журналов: секундный рассинхрон архива и микросекундный джиттер задачи - разные болезни, их путают на разборе ночной аварии.
Короткий ответ
Distributed Clocks EtherCAT синхронизируют метку времени и SYNC-события между slave (приводы, модули I/O), обычно с ошибкой единицы микросекунд, если цепочка собрана и DC включён. Задача ПЛК по IEC 61131-3 живёт своим периодом: 1 мс, 4 мс, 10 мс. Джиттер этой задачи - разброс момента, когда runtime реально отработал цикл и выложил PDO. DC не выравнивает этот момент сам по себе.
Если интерполятор motion и технологическая программа сидят на одном CPU, визуализация и OPC-сервер крадут кванты, цикл «иногда» уезжает за watchdog. Привод по DC отрабатывает старый или поздний setpoint идеально синхронно с соседом. Тренд SCADA с дискретизацией 500 мс…1 с это не видит: алиасинг прячет пульсацию.
Мерить нужно три независимых канала: отклонение DC и Working Counter на мастере, min/max/jitter задачи в runtime, scope привода (following error, момент). Не график историка.
Двое часов в одном шкафу
На объекте с EtherCAT легко получить ложное спокойствие. Мастер показывает «DC in sync». Приводы в CSP (Cyclic Synchronous Position) принимают setpoint каждый цикл шины. Оси «как часы» в слайде вендора. При этом задача, которая считает траекторию и копирует PDO, стартует когда свободный квант Linux RT или runtime IEC это позволяет. Если в этот же контроллер повесили тяжёлую мнемосхему, опрос OPC UA и медленный контур клапанов, квант кончается не там, где написано в конфигурации задачи.
Distributed Clocks - механизм шины: выбирается reference clock (часто первый DC-capable slave), остальные подтягивают системное время, мастер генерирует или подстраивает SYNC0/SYNC1. Цель - чтобы токовые контуры и интерполяторы приводов сэмплировали одновременно, а распределённые входы защёлкивались одной меткой. Это решает фазу между устройствами поля. Это не делает детерминированным момент, когда приложение ПЛК положило новый setpoint в буфер.
Задача IEC - контракт приложения с runtime: период, приоритет, watchdog, иногда отдельный motion task. Джиттер задачи - не история про «среднее в допуске, и ладно». Для CSP разброс 200…400 мкс на цикле 1 мс уже даёт рывок момента и рост following error, особенно на жёсткой механике. Для пневмоклапана с временем хода 80 мс тот же разброс незаметен. Беда начинается, когда оба живут в одной задаче или делят данные без согласованного снимка.
Путаница с NTP здесь системная. NTP на ПЛК, панели и сервере архива нужен, чтобы журналы событий сходились по секундам. Про это - отдельный разбор синхронизации времени и фантомных аварий. DC и jitter задачи - про микросекунды внутри цикла управления. Выровнять часы Windows на историке и «починить дёрганье оси» одной заявкой IT нельзя.
Что реально делает DC, а что нет
DC включён в конфигурации slave и мастера. На живой линии это проверяется не галочкой в проекте, а диагностикой: отклонение системного времени slave относительно reference, стабильность SYNC0, отсутствие постоянных пересинхронизаций после «пошевелили кабель». Типичные цифры «в норме» на компактной линии - единицы микросекунд. Если отклонение скачет на десятки и сотни микросекунд, сначала ищут физику и топологию, не PID оси.
DC не компенсирует:
обрыв и переподключение ветки, после которого часть slave ушла в resync, а мастер продолжает слать PDO;
несогласованный цикл мастера и период задачи (мастер 1 мс, задача 2 мс «чтобы легче жилось»);
смешение DC-устройств и устройств без DC в одной надежде, что «шина всё равно синхронная»;
позднюю запись setpoint из задачи, которая в этом цикле не успела.
Второй пункт недооценивают. Мастер EtherCAT может отрабатывать свой цикл по своему таймеру. Задача IEC - по своему. Если их не связали (синхронный режим задачи с шиной, привязка к SYNC, копирование PDO в одном детерминированном месте), получаются биения: иногда задача попадает «в такт», иногда пишет через раз, иногда дважды затирает одно и то же. На тренде SCADA это выглядит как редкий выброс положения - если вообще попал в секундную точку.
Выбор EtherCAT как шины поля под короткий цикл - другая задача, её не повторяем: полевая шина на новый объект. Здесь шина уже выбрана. Вопрос - кто в шкафу хозяин времени: DC, задача или историк.
Задача IEC: период, который врёт средним
В конфигурации задач пишут Cycle time = 1 мс и живут. Runtime считает среднее, и оно красивое. Авария живёт в хвосте распределения: один цикл из тысячи длится 1,8 мс, watchdog 2 мс ещё молчит, привод уже получил setpoint с дыркой.
Что смотреть в мониторе задачи, а не в SCADA:
фактический минимум, максимум, среднее периода;
jitter (разброс старта относительно идеальной сетки);
счётчик превышений (exceeded / timeout / watchdog);
загрузку CPU по задачам, не «общий % проца» с панели.
Если motion task 1 мс, main 10 мс, vis 50 мс, а OPC UA и логгер не вынесены, main и vis регулярно отъедают квант у motion. На Linux RT это не абстракция: поток визуализации и поток IEC делят ядра. Приоритеты в проекте и приоритеты ОС - два слоя. Выставить «High» задаче в IEC и оставить тяжёлый экран на том же ядре - получить джиттер, который «иногда».
Связка motion и процесса на одном контроллере сама по себе не запрещена. Запрещено делать вид, что у них один бюджет времени. Клапаны, PID 100 мс, рецепт, связь с частотниками по другому протоколу - в медленную задачу. Интерполятор, копирование PDO осей, быстрые блокировки по входам с DC-модулей - в быструю. Обмен между задачами - через буфер с согласованным кадром (консистентное копирование), не через «глобальный REAL, который кто-то пишет в обоих циклах».
Типичный симптом неправильного обмена: ось отрабатывает ступеньку уставки, которой технолог «не давал». Её породила медленная задача, перезаписав слово посередине цикла motion.
Motion плюс процесс: где ломается фаза
Сценарий средний и частый. Три оси упаковки или позиционера, плюс транспортёр, плюс пневмоостров, плюс пара аналоговых контуров. Всё в одном ПЛК, потому что «железки хватает». Хватает среднего. Не хватает хвоста.
Оси в CSP ждут новый setpoint каждый DC-такт. Если задача опоздала, привод либо держит предыдущую точку (интерполирует в никуда относительно задуманной траектории), либо получает две точки сразу в следующем удачном цикле. Following error растёт не монотонно, а пачками. Пачки редко попадают в архив 1 с.
Клапан на том же контроллере открывается «с задержкой», которую списывают на пневмоостров. Реже проверяют, что команда клапану уехала в том же сорванном цикле, что и ось, или наоборот: клапан в 20 мс задаче, ось в 1 мс, а разрешение движения - бит из медленной задачи без снимка. Тогда фаза «ось поехала, прижим ещё не закрыт» плавает. На SAT это ловят случайно. В эксплуатации - «иногда».
Отдельно - Home и состояние оси. Джиттер цикла не заменяет кривую конфигурацию энкодера и лимитов, но маскируется под неё. Если после MC_Home ось стабильно в ErrorStop, сначала конфигурация и привод, не DC: SoftMotion, ось после Home. Если Home проходит, а на установившемся движении «дрожит момент» при зелёном тренде SCADA - тогда DC, задача и сеть.
Почему тренд 1 с слепой
Историк и тренд оператора - инструмент смены и разбора событий секундного масштаба: уставка, авария, открытие клапана. Период записи 500 мс, 1 с, иногда 5 с «чтобы не раздувать базу». Теорема отсчётов здесь не лозунг: пульсация 200…500 Гц на следующем ошибке оси при записи 1 Гц не восстанавливается. Видно среднее или случайную точку. «График ровный» - ожидаемый результат, не доказательство отсутствия джиттера.
Алиасинг даёт ещё хуже: редкие выбросы following error попадают в архив как одиночные пики «помеха», либо не попадают вовсе. Оператор прав: на его экране ровно. Привод тоже прав: в своём scope на 1 мс пила.
Что тренд SCADA умеет поймать по этой теме: длительный рост following error, аварию оси, пропадание связи на секунды, рассинхрон меток событий между узлами, если часы журналов разъехались (снова NTP, не DC). Что не умеет: микросекундный jitter задачи, отклонение DC в 8 мкс, пропуск одного PDO.
Для FAT контура motion в протокол приёмки нельзя писать «проверено по тренду SCADA». Нужна запись с привода или с мастера с периодом цикла, плюс монитор задачи за оговорённое время нагрузки (экран открыт, OPC подписан, рецепт едет).
Чем мерить: три канала, не один график
Первый канал - шина. На мастере: Working Counter (кадр обработан всеми slave), потерянные кадры, состояние DC (in sync / sync error), величина отклонения clock, факты переинициализации после обрыва. Скачок WC при «дёрганье» оси - сначала кабель, экран, разъём, лишний коммутатор в цепочке, не коэффициент регулятора.
Второй канал - задача. Монитор runtime: период, jitter, exceeded. Дополнительно - дискретный выход, который задача инвертирует на старте цикла, и осциллограф: это единственная честная картинка «когда цикл реально начался» относительно SYNC или относительно входа. Если выход дёргается с разбросом 300 мкс, а DC держит 2 мкс, виновата не шина.
Третий канал - привод. Scope: setpoint, actual, following error, ток. Пачки ошибки следования с периодом, кратным задаче, а не механическому резонансу - сильный аргумент в сторону jitter приложения. Механический резонанс и люфт дают другую форму и не коррелируют с exceeded задачи.
Клапан и «медленный» процесс: те же три канала, другие пороги. Смотрят момент команды в задаче, задержку PDO до модуля, фактическое давление/концевик. Если команда в программе ушла вовремя, а модуль I/O без DC получил её в произвольной фазе относительно осей - это уже рассинхрон не задачи, а модели копирования. Лечится не «побыстрее цикл main», а разделением и DC на тех входах, которые участвуют в фазе с motion.
Не мерить «на глаз по мнемосхеме». Анимация панели обновляется ещё реже тренда и живёт своим циклом vis.
Нагрузка, которую не видно в простое
Пустой контроллер на столе: jitter микросекунды, DC идеален, SAT «зелёный». В цеху открыты три экрана, историк подписан на тысячу тегов, смены пишут уставки, ночной отчёт выгружается. Бюджет CPU съеден. Именно поэтому замер джиттера делают в режиме, близком к эксплуатации: vis включена, подписки живые, типовой рецепт едет. Замер «в STOP визуализации» годится только как базовая линия.
Симптом: ночью при малом числе клиентов ровно, в дневную смену «дёргает». Ищут не технолога, а нагрузку задач и сети мастера. Лишний сканер OPC, который вычитывает весь адресный космос каждый цикл, даёт тот же эффект, что тяжёлая мнемосхема.
Что фиксировать в проекте и на FAT
В конфигурации: период и приоритет motion-задачи, привязка к циклу мастера/SYNC если среда это умеет, watchdog меньше «терпеливого» значения «чтобы не сыпало», отдельная задача процесса, список PDO осей, DC включён на нужных slave, запрет офисного свитча в середине цепочки.
В протоколе FAT: скрин/выгрузка монитора задачи под нагрузкой (max, jitter, exceeded = 0 за оговорённый интервал); диагностика DC (отклонение в допуске); scope привода на типовом перемещении; тест обрыва кабеля и время re-sync; явно: тренд SCADA не является доказательством детерминизма цикла.
В ТЗ бесполезно писать «синхронизация осей 1 мкс» без указания, чем подтверждают, и без бюджета задач. Полезная формулировка: DC deviation не более N мкс в диагностике мастера; jitter motion-задачи не более M мкс при включённой визуализации и K OPC-подписках; following error на профиле X не превышает E.
Таблица: симптом, слой, чем мерить
| Симптом на оси / клапане | Слой: DC / задача / сеть | Чем мерить |
|---|---|---|
| Оси «плывут» друг относительно друга, DC error, после шевеления кабеля уходит и возвращается | DC + физика цепи | Диагностика DC deviation, факт resync; осмотр разъёмов; запрет случайного свитча в линии |
| Оси синхронны между собой, но обе дёргают момент пачками, exceeded задачи > 0 | Задача IEC | Монитор min/max/jitter; осциллограф на выходе «старт цикла»; отключить vis/OPC и сравнить |
| Ровный тренд SCADA 1 с, на приводе пила following error с периодом цикла | Задача (алиасинг архива) | Scope привода с дискретизацией цикла; не историк |
| Клапан открывается «когда придётся» относительно хода оси | Обмен задачами / нет снимка | Трасса бита разрешения в motion vs main; консистентное копирование; DC на дискретном входе, если фаза критична |
| Редкий пропуск хода, WC скачет, Lost frames | Сеть EtherCAT | WC, lost frames, топология, экран кабеля, длина, ответвление |
| После Home стабильный Fault, в симуляторе ок | Не DC (конфиг оси/привода) | Статус оси, лимиты, энкодер, MC_Power; не разбор джиттера |
| Ночью ровно, днём дёргает при тех же уставках | Нагрузка задач / подписки | Замер jitter при открытых экранах и живом OPC; список клиентов |
| Плавный рост following error без пачек, DC в норме, задача в норме | Механика / настройка контура | Scope момента и скорости; не шина |
| Метки событий оси и клапана в журналах разъехались на секунды | Часы NTP/архива, не DC | Сверка часов узлов; не микросекундный DC |
| Мастер 1 мс, задача 2 мс, «иногда две уставки, иногда ни одной» | Рассинхрон цикла мастера и задачи | Конфиг периодов; привязка задачи к SYNC; трасса PDO |
Таблица не заменяет методику вендора мастера. Она отсекает привычку открывать SCADA первой.
Типовые ошибки
Считать «DC in sync» доказательством детерминизма приложения. Синхронны slave. Задача может опаздывать отдельно.
Принимать линию по тренду 1 с. Алиасинг прячет ровно ту неисправность, из-за которой привод в Fault на жёстком профиле.
Сажать интерполятор, PID клапанов, vis и OPC в одну задачу «так проще». Проще до первого совпадения нагрузки.
Лечить дёрганье оси фильтром уставки в SCADA. Фильтр историка не уменьшает jitter PDO.
Сравнивать симулятор SoftMotion и объект по «плавности графика». Симулятор не эмулирует DC, WC и конкуренцию vis за CPU.
Писать в ТЗ «синхронизация 1 мкс» без канала измерения. На SAT это становится спором о скрине.
Мешать NTP-разбор журналов и DC. Секунда в архиве и 80 мкс на оси - разные заявки.
Искать резонанс механики, не сняв exceeded задачи. Сначала хвост цикла, потом шпиндельная диагностика.
Вопросы при работе
Можно ли оставить одну задачу 4 мс на оси и клапаны, если «оси не быстрые»?
Можно, если профиль и механика это терпят и jitter измерен под нагрузкой. Нельзя переносить допуск клапана на CSP 1 мс без замера following error.
DC включён, а приводы всё равно не вместе. С чего начать?
Отклонение clock и resync, затем физика цепи, затем периоды мастер/задача. Регулятор оси - после того, как три канала времени зелёные.
Почему на столе jitter 20 мкс, в шкафу 400?
Vis, подписки, второй протокол, запись архива, хуже тепловой режим CPU. Повторить замер как в эксплуатации.
Тренд SCADA с периодом 100 мс спасёт?
Лучше, чем 1 с, для клапана. Для цикла 1 мс всё ещё слепой. Нужен scope цикла.
Нужен ли отдельный контроллер на motion?
Когда бюджет задач на одном CPU не сходится в замере под нагрузкой, а резать vis и OPC нельзя. Не «потому что так солиднее».
Это то же самое, что NTP для журналов?
Нет. NTP - чтобы смена и разбор аварии видели один порядок секунд. DC и jitter - чтобы приводы получили setpoint в свой такт.