Перейти к содержанию
8 (800) 302-57-71

Диагностика EtherCAT: как найти ошибку по состоянию slave и Working Counter

На обложке использовано официальное изображение контроллера Systeme Electric SM253CE10. Инженерные схемы подготовлены редакцией SMARTHOFF.

Материал подготовлен и проверен инженерной редакцией SMARTHOFF. Дата публикации: 15 августа 2026.

Если EtherCAT slave не выходит в OP, пропадает из сети или master сообщает об ошибке Working Counter, не стоит одновременно менять кабель, ESI-файл, PDO и настройки Distributed Clocks. Сначала нужно определить первый этап, на котором система перестала работать штатно: физическая связь, обнаружение топологии, переход состояния, обмен process data или синхронизация.

Диагностика идет от простого к сложному: питание и Link Status, фактическая топология, состояние конкретного slave, AL Status Code, ожидаемый и фактический WKC, счетчики ошибок портов, конфигурация PDO/SyncManager и только затем Distributed Clocks. Один зафиксированный симптом и одна контролируемая правка за раз дают больше информации, чем полный сброс проекта «на всякий случай».

Какие диагностические сигналы дает EtherCAT

EtherCAT позволяет не только обнаружить нарушение обмена, но и сузить участок поиска. В официальном описании технологии EtherCAT Technology Group отдельно указывает на сравнение фактической и проектной топологии, Link Status, сведения об ошибках узлов и Working Counter.

Эти признаки отвечают на разные вопросы:

  • Link Status показывает наличие физической связи на порту, но сам по себе не подтверждает корректный циклический обмен.
  • Фактическая топология помогает увидеть, какие устройства ответили при сканировании и где сеть перестала соответствовать проекту.
  • Состояние slave показывает, до какого этапа EtherCAT State Machine дошло устройство: INIT, PREOP, SAFEOP или OP.
  • AL Status и AL Status Code уточняют, почему slave отклонил переход либо покинул рабочее состояние.
  • Working Counter, или WKC, показывает, сколько ожидаемых операций конкретного EtherCAT datagram было успешно обработано.
  • Счетчики порта и приема помогают искать участок с ошибками кадра, потерей link или нестабильным соединением.
  • PDO, SyncManager и watchdog относятся уже к организации process data и контролю их своевременного поступления.
  • Distributed Clocks проверяют отдельно, если проект действительно использует синхронизацию устройств по распределенным часам.

Поэтому сообщения «EtherCAT error» или «slave not operational» недостаточно. Для нормальной диагностики нужны состояние устройства, код, момент появления ошибки и информация о том, что происходило на предыдущем этапе.

Цепочка диагностики EtherCAT от питания и Link Status до Distributed Clocks
Проверка идет по цепочке: питание и link, топология, состояние slave, AL Status, WKC, process data и только затем Distributed Clocks.

Порядок диагностики EtherCAT

1. Зафиксируйте исходный симптом

До сброса ошибки сохраните время события, состояние master и каждого slave, ожидаемый и фактический WKC, AL Status Code, сообщения журнала и состав найденной сети. Если ошибка периодическая, отметьте, связана ли она с запуском привода, переключением силовой нагрузки, прогревом шкафа, заменой модуля или перезапуском питания.

Не начинайте со сброса всех счетчиков: после подтверждения ошибки часть диагностической информации может измениться или потерять смысл.

2. Проверьте питание и физическую связь

Сверьте питание master и slave, состояние разъемов, Link LED и первый участок линии. Если все устройства после определенной точки одновременно исчезли из сканирования, в первую очередь проверяют питание и соединение непосредственно перед этой точкой, а не каждый последующий slave по отдельности.

Наличие Link LED подтверждает только физический link. Оно не доказывает, что кадры проходят без ошибок, устройство идентифицировано правильно и process data обрабатываются.

3. Сравните фактическую топологию с проектной

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

Если после замены модуля сеть физически собирается, но конфигурация не принимается, проверьте точную модель, revision, ESI и структуру модулей. Похожий корпус или совместимый разъем не означают идентичную process-data конфигурацию.

4. Найдите первое устройство с неправильным состоянием

Проверяйте не последнее устройство, которое отображается красным, а первый slave, который не отвечает или не подтверждает требуемый переход. Ошибка в одном участке может сделать недоступными все расположенные после него устройства и создать впечатление множественной неисправности.

Состояние также сужает область поиска. INIT указывает на самый ранний этап. PREOP означает, что mailbox-коммуникация уже возможна, но process data еще не работают. В SAFEOP доступны входные process data, а выходы остаются в безопасном состоянии. OP означает, что входы и выходы переведены в рабочий обмен. Это разделение описано в официальном материале ETG по EtherCAT State Machine.

5. Считайте AL Status и AL Status Code

AL Status показывает фактическое состояние и Error Flag, а AL Status Code уточняет причину, которую сообщил slave. Среди возможных групп — неправильная конфигурация SyncManager, отсутствие допустимых входных или выходных данных, watchdog, ошибка синхронизации, неверная настройка DC или неготовность внешнего оборудования.

Код нужно читать в контексте конкретного перехода. Например, отказ PREOP → SAFEOP и выпадение из OP относятся к разным этапам, даже если внешне оба случая выглядят как «устройство не работает». ETG отдельно описывает диагностическое назначение AL Status и AL Status Code.

6. Сравните ожидаемый и фактический Working Counter

Каждый EtherCAT datagram содержит Working Counter. Устройство увеличивает его, когда адресованная операция с доступной областью памяти выполнена успешно. Master знает ожидаемое значение для конкретного datagram и сравнивает его с фактическим.

Если WKC отличается от ожидаемого, это подтверждает, что одна или несколько ожидаемых операций не выполнены. Но WKC не объясняет причину: это может быть потеря устройства, неправильное состояние slave, недоступная область, несоответствие конфигурации или физическая ошибка. Поэтому WKC нельзя автоматически приравнивать к числу устройств в линии.

Разница между Working Counter, состоянием slave и AL Status Code
WKC, состояние slave и AL Status Code отвечают на разные диагностические вопросы и должны анализироваться вместе.

7. Проверьте счетчики портов и ошибок приема

После WKC переходят к данным конкретных портов: Link Status, lost link, Rx/CRC и другим доступным счетчикам. Смотрите не только итоговое значение, но и динамику: растет ли счетчик во время появления симптома и на каком устройстве это происходит первым.

В диагностическом примере ETG ошибка приема на одном slave приводит к последующим симптомам на уровне process data и WKC. Это полезная логика поиска, но не универсальный диагноз: растущий счетчик нужно сопоставить с топологией, состоянием устройства и журналом master. Официальный набор материалов EtherCAT Diagnosis for Users как раз построен вокруг таких сценариев локализации.

8. Проверьте ESI, PDO, SyncManager и watchdog

Если физическая сеть обнаружена, а переход в SAFEOP или OP не проходит, сверяют ESI-файл и revision устройства, назначение PDO, длину и направление process data, настройки SyncManager и требования watchdog.

Не загружайте случайный ESI только потому, что совпало название серии. Не меняйте одновременно PDO mapping, цикл и watchdog: после нескольких правок невозможно понять, что именно повлияло на результат.

9. Проверьте Distributed Clocks, если они нужны проекту

DC имеет смысл диагностировать отдельно от обычного link и WKC. Проверьте выбранные DC-устройства, reference clock, наличие Sync-событий, состояние синхронизации и соответствие настроек требованиям конкретных master и slave.

Интерфейс и названия диагностических полей зависят от runtime. Например, в документации Beckhoff по Distributed Clocks Diagnosis анализируются распределение временных отклонений и их асимметрия. Эти поля полезны как пример подхода, но их нельзя превращать в универсальные пороги для любого EtherCAT-проекта.

10. Повторите тест после одной правки

После изменения кабеля, питания, ESI, PDO или DC-настройки повторите одинаковую последовательность: сканирование, состояние slave, AL Status Code, WKC и счетчики. Запишите, что изменилось. Такой журнал быстро отделяет устойчивое исправление от случайного исчезновения симптома.

Почему WKC и состояние OP не дают полного диагноза

Working Counter отвечает на узкий вопрос: выполнено ли ожидаемое количество операций в конкретном datagram. Он не сообщает, что причиной является именно кабель, и не обязан совпадать с количеством slave. Ожидаемое значение зависит от адресации, типа операции и доступности соответствующей области памяти.

Состояние OP тоже не является итоговым сертификатом здоровья системы. Устройство может находиться в OP, но приложение при этом получает неверно интерпретированные данные из-за неподходящего PDO mapping, неправильного масштаба или типа данных. Возможны и периодические нарушения, которые проявляются только при определенном режиме нагрузки.

Практическое правило простое: WKC подтверждает нарушение ожидаемой обработки datagram, state machine показывает этап работы slave, AL Status Code уточняет заявленную устройством причину, а счетчики и журнал помогают найти участок. Диагноз появляется только после сопоставления этих данных.

Таблица типовых симптомов

Симптом Индикатор или этап Возможная группа причин Что проверить Чего не делать
Slave не обнаруживается Link и сканирование Питание, разъем, линия до устройства, неисправность порта Питание, Link LED, первый недоступный участок Не менять PDO и DC до появления устройства
Найдено меньше устройств, чем в проекте Фактическая топология Обрыв или потеря питания перед первой пропавшей группой Первую позицию расхождения и устройство перед ней Не проверять все последующие slave как независимые отказы
Slave остается в PREOP ESM, mailbox/configuration ESI, идентификация, mailbox или начальная конфигурация Точную модель, revision, ESI и AL Status Code Не подменять ESI файлом похожей модели
Slave не выходит в SAFEOP ESM, process-data configuration PDO, SyncManager, модульный состав Mapping, длины и направления process data Не менять одновременно mapping и cycle time
Slave не выходит в OP SAFEOP → OP Нет допустимых outputs, watchdog, DC или внешняя готовность AL Status Code, поступление process data, DC и внешние разрешения Не считать это автоматически дефектом кабеля
WKC ниже ожидаемого Cyclic datagram Устройство не обработало ожидаемую операцию Какой datagram ошибочен, состояния slave и топологию Не приравнивать WKC к числу устройств
Растут Rx/CRC counters Порт или линия Нестабильное соединение, помеха, разъем или порт Первый счетчик, растущий одновременно с симптомом Не заменять всю сеть без локализации участка
Slave периодически выпадает из OP ESM и журнал Потеря process data, watchdog, питание, link или приложение Время события, AL Status Code, WKC и счетчики Не сбрасывать журнал до фиксации причины
Сообщение watchdog Process data Не поступают ожидаемые данные или нарушен временной режим Цикл, SyncManager, состояние master и поток process data Не увеличивать watchdog без анализа проекта
Ошибка DC или Sync Distributed Clocks DC-конфигурация, reference clock, Sync-события или timing задачи Руководства конкретных master/slave и DC diagnostics Не применять чужой универсальный порог
Ошибка появилась после замены модуля Identification и configuration Другая модель, revision, ESI, PDO или состав модулей Маркировку, revision, ESI и проектную конфигурацию Не считать одинаковый корпус доказательством совместимости

Схожие группы причин для неправильного Working Counter и изменения числа slave приводит и официальная справка ABB/CODESYS по EtherCAT troubleshooting. Названия сообщений в другой среде могут отличаться, но последовательность проверки остается той же.

Distributed Clocks: когда проверять синхронизацию

Distributed Clocks нужны там, где устройства должны выполнять действия относительно общей временной базы: например, в синхронном движении или распределенном измерении с жесткими требованиями ко времени. Для обычного обмена I/O наличие EtherCAT само по себе не означает, что DC нужно включить у каждого устройства.

Если сеть работает без ошибок link и topology, но slave отказывается переходить из SAFEOP в OP либо приложение сообщает о нарушении синхронизации, проверяют поддержку DC конкретными устройствами, выбранный reference clock, Sync-события, цикл и timing задачи master. Числовые критерии берут только из документации используемой связки и проекта.

Пример контроллера SM253CE10

В официальной карточке Systeme Electric для SM253CE10 заявлены порт EtherCAT и среда CODESYS 3.5 SP18. Руководство по линейке S250 также описывает интерфейс EtherCAT и архитектуру расширения для конкретных моделей.

Этой информации недостаточно, чтобы по одной строке карточки объявить контроллер совместимым с любым slave. Перед проектированием нужно подтвердить роль устройства в нужной конфигурации, версии runtime и firmware, ESI, PDO, требуемый режим Distributed Clocks, cycle time и реакцию на потерю связи.

Поэтому оборудование выбирают не по фильтру «есть EtherCAT», а по полной матрице проекта. В каталоге SMARTHOFF можно предварительно посмотреть контроллеры и модули ввода-вывода, но окончательный состав проверяют по документации точных моделей.

Что проверить до закупки EtherCAT-оборудования

  1. Какое устройство выполняет роль master, а какие — slave.
  2. Какие версии firmware, runtime и среды разработки используются.
  3. Есть ли актуальный ESI для точной модели и revision.
  4. Какие PDO, типы данных и направления обмена нужны.
  5. Как настроены SyncManager и контроль process data.
  6. Нужны ли Distributed Clocks и какие устройства их поддерживают.
  7. Каковы проектные требования к cycle time и watchdog.
  8. Как выглядит физическая топология и питание удаленных узлов.
  9. Какие диагностические данные доступны master и HMI.
  10. Что должна сделать система при потере одного slave или участка сети.

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

Данные, которые нужно сохранить до сброса ошибки EtherCAT
До сброса ошибки сохраните состояние сети, коды, счетчики и конфигурацию: без них периодический отказ сложнее локализовать.

Что передать инженеру SMARTHOFF

Для проверки совместимости и разбора неисправности подготовьте:

  • модели master и всех проблемных slave;
  • версии firmware, runtime и ESI;
  • проектную и фактическую топологию;
  • состояние каждого slave;
  • ожидаемый и фактический WKC;
  • AL Status, AL Status Code и Diagnosis History;
  • счетчики link/Rx/CRC по портам;
  • настройки PDO, SyncManager и watchdog;
  • режим Distributed Clocks и проектный cycle time;
  • перечень требуемых I/O и функции HMI/SCADA;
  • журнал выполненных замен и изменений.

По этим данным можно оценить, на каком уровне находится проблема, и проверить состав оборудования. Один скриншот с общей ошибкой для такой проверки обычно недостаточен.

Частые вопросы

Почему EtherCAT slave виден, но не выходит в OP?

Обнаружение устройства подтверждает только часть цепочки. Переход в OP может блокироваться из-за process-data configuration, SyncManager, watchdog, Distributed Clocks, внешней готовности оборудования или другой причины, указанной в AL Status Code. Начните с фактического состояния и кода отказа перехода.

Что означает Working Counter error?

Фактический WKC не совпал с ожидаемым для конкретного datagram. Это означает, что не все ожидаемые операции были успешно обработаны. Причину ищут по топологии, состояниям slave, AL Status и счетчикам портов; сам WKC не указывает автоматически на неисправный кабель.

Почему один неисправный кабель может выглядеть как ошибка нескольких slave?

Если линия нарушена перед группой устройств, все расположенные после точки отказа могут перестать отвечать. Поэтому сначала находят первую позицию расхождения фактической и проектной топологии.

Нужно ли включать Distributed Clocks в каждом EtherCAT-проекте?

Нет. DC используют, когда проекту требуется согласованная временная база и устройства поддерживают нужный режим. Решение принимают по задаче, документации master/slave и требованиям к синхронизации.

Почему после замены модуля не совпадает конфигурация EtherCAT?

Могут отличаться точная модель, revision, идентификация, ESI, PDO mapping или модульный состав. Перед изменением проекта сравните маркировку нового устройства и его официальную документацию с исходной конфигурацией.

Что проверить при выборе контроллера с EtherCAT?

Проверьте роль в проекте, runtime и firmware, ESI, PDO, нужные типы данных, Distributed Clocks, cycle time, watchdog, топологию, диагностику и реакцию системы на потерю связи. Наличие слова EtherCAT в карточке — только первый фильтр.

Первичные источники


15.08.2026, 49 просмотров

Закрытый предпросмотр

Отправка запросов отключена. Данные не передаются в CRM и по почте.