Вебинар. Механизм распределенного времени

5 июля прошел вебинар по механизмам распределенного времени (EtherCAT | Distributed Clocks: Functional principle, application and diagnostics). Это простая в использовании технология и просто гигантская по объему, если копнуть чуть глубже. Как и вайфай — все пользуются, но мало кто знает как это работает внутри. По сути, вебинар пересказывает содержимое справочной системы, раздел Distributed Clocks, где кратко даны выдержки из документации по EtherCAT. Пришлось разбавить краткость дополнительными материалами.

Основы

В каждом устройстве поддерживающем DC, есть те или иные счетчики, ведущие отсчет времени или временных интервалов. Устройств много и у каждого свое время, но все они находятся на одной шине. Мастер шины, в нашем случае — это ПК/ПЛК с TwinCAT, старается циклически и как можно чаще отправлять пакет данных с сигналом о синхронизации.

Не все подчиненные должны, и не все поддерживают часы распределенного времени (DC [ди́-си́], Distributed Clock). Просто не всем оно нужно и наличие его — не делает модуль лучше.

Для начала, кто-то из подчиненных становится эталоном распределенных часов (reference clock). Это просто одно из подчиненных устройств (даже не мастер шины) с достаточно точным и стабильным источником временных отсчетов. Обычно, это первое устройство на шине, поддерживающее DC. Остальные устройства с поддержкой DC синхронизируются с этими часами (включая мастера), то есть они отстраивают свои часы согласно этому эталонному устройству.

Распределенное время — это не какое-то всемирное время или время дня, суток или время прошедшее с момента старта устройства, а просто некий счетчик для DC-часов, позволяющий синхронизировать временные интервалы. 

Плюс-минус 50-100 наносекунд — это обычная точность распределенных часов. Счетчик 64-разрядный, его должно хватить где-то лет на 500. Тикает он, согласно спецификации, с 10 наносекундным интервалом.

Железо

Внутри EthreCAT ASIC-чипа есть специальный блок ESC (EtherCAT Slave Controller) в том числе отвечающий за DC. Запуск системы часов распределенного времени состоит их нескольких фаз, первой из которых является измерение задержки распространения (propagation delays).

Каждый из подчиненных внутри себя имеет входную и выходную отметки времени, по которым можно легко вычислить на сколько задерживается пакет на каждом из подчиненных. Этот процесс контролирует мастер шины, отправляя одну или несколько широковещательных команд BWR (Broadcast Write). Эта команда адресует специальный регистр DC Receive Time Port, расположенный по адресу 0x0900.

После сбора всех временных отметок (time stamps), мастер шины, который отлично знает топологию шины, может рассчитать задержки распространения для каждого сегмента кольца шины. Затем, для каждого подчиненного, который умеет DC, мастер индивидуально записывает в специальный регистр System Time Offset смещение между эталонным временем и локальным отсчетом времени. Размер регистра те самые 8 байт или 64 разряда расположенные по адресу 0x0920. Теперь каждый DC-подчиненный может узнать системное время просто сложив свое локальное время (хранящееся в регистре Local Time) со сдвигом (offset).

Со временем локальные часы могут "уплыть" в большую или меньшую сторону, поэтому мастеру необходимо постоянно корректировать это отклонение (drift). Для этого постоянно отправляются специальные команды ARMW (Auto Increment Read Multiple Write) или FRMW с эталонным временем.

Эта команда всегда отправляется в самой быстрой задаче.

Подчиненное устройство (терминал) получив эту команду, сверяет значение локального времени и ускоряет или замедляет свои локальные часы.

Режимы работы

На вкладке DC → Operation Mode, можно увидеть следующие варианты режимов работы распределенных часов:

• Oversampling — с оверсамплингом, можно задать частоту отправки SyncUnit и частоту семплера, который для получения дополнительных отсчетов работает быстрее SyncUnit.
• DC Latch — только с DC, не работает без него.
• FreeRun / SM-Synchron — синхронизация по фреймам EtherCAT.
• DC-Synchron / DC-Synchron (input based) — TwinCAT делит устройства на группу ввода и группы вывода (плюс информационная зеленая группа). DC может синхронизироваться или там, или там. Этот вариант позволяет выбрать откуда подчиненное устройство будет брать DC-сигнал.

Тонкая настройка

I/O → devices → EtherCAT шина → EtherCAT - Advanced Settings... → Distributed Clocks

DC Mode → Automatic DC Mode Selection — по умолчанию, установлен и означает автоматический выбор эталонных часов. Обычно, этот выбор правильный.

Settings→ Continuous Run-Time Measuring — регулярно пересчитывать карту временных задержек. Применимо в случаях частой замены кабелей связи, либо при использовании групп горячего подключения (кабель может быть другой и он будет другой длины).
→ Sync Windwos Monitoring → Sync Window (мкс) — уровень предупреждения при выходе за пределы.
→  Show DC System Time — это копия системного времени, а не локальное DC-время! Отображается в желтой закладки Input, но(!) отстает на один цикл от точного значения, так как необходимо время на получение и отображение значения. В ПЛК-программе лучше использовать множество  функций из библиотек TcEthercat, которые дадут точное время.

SYNC Shift Time — сдвиг времени, обычно автоматически определяется правильно при старте системы. При условии, что система работает и построена правильно.

Диагностика

Diagnosis — у нас есть два отсчета DC-времени: системное — эталонное и локальное. Они немного отличаются. Даже в жесткой цикличности все-равно есть небольшие отклонения (deviation), которые тем не менее не должны привести к сбою синхронизации. Нужно постоянно подстраиваться. Здесь мы можем посмотреть на срез подстройки: в самом низу, проценты не должны убегать далеко от 50%.

Slave Diagnosis — диагностика подчиненного, появилась в TwinCAT 3. Здесь можно тестировать и смотреть графики, а затем регулировать SYNC Shift Time.

Хозяйке на заметку

• Wc-Error (working counter) — возможно необходимо поднастроить SyncUnit или подчиненный вообще выпал из рабочего режима (не в том режиме).
• Теряете фреймы (Lost frames) — проверьте CRC.
• Возможно, не хватает питания на EtherCAT-шине.
• Проверьте целостность кабелей и разъемов.
• Возможно неправильно отрегулированы DC-часы.
• Для оптоволокна (EK1122, EK1100) — проверьте правильно ли выбраны порты: часто путают входные-выходные.
• Проверьте DC Diagnosis: deviation должен быть рядом с 50% (51% / 48%).
• Идем глубже: в онлайн режиме проверьте у подчиненного ESC регистр 0x0910.
• Также проверить работает ли отсчет SYNC0/1 в регистре 0x0990?
• Если вдруг и внезапно все показатели равны 4.2 секунды, то возможно у вас модуль с оверсемплингом и вы получили переполнение 32-разрядных регистров.
• Слишком малое время цикла. Учитывайте, что на пересылку 1400-байтного пакета EtherCAT требуется порядка 125 микросекунд.
• Большой jitter — включите IO at task begin.
• Для перезапуска DC — мастер должен побывать в INIT состоянии.
• Кто эталон? Всегда хороший выбор — это коплер Бекхофф EK1100, так как в нем установлен ASIC-чип Beckhoff, а он очень стабильный и красивый.
• Большое количество Queued Frames — все очень плохо, систему нужно переконфигурировать или перестроить с начала и совсем.
• CU2508 поддерживает до 4-х колец с резервированием линий и DC.