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

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.

Вебинар. Оптимизация нагрузки многоядерных систем TwinCAT 3

30 июня Кнут Гётель провел вебинар на тему оптимизации нагрузки многоядерных систем в TwinCAT 3 (TwinCAT 3 | Optimised utilisation of multi-core features). Большая часть нюансов многозадачности в TwinCAT 3 уже рассматривалась, поэтому далее только крошки.


Как обстоят дела в TwinCAT 2:

• Рантайм может исполнятся только на одном ядре.
• Рантайм работает только в 32-х разрядных системах.
• Выбор ядра на котором будет выполняться рантайм производится через реестр (можно считать, что 98% пользователей об этом не знает).

Однако, большинство современных процессоров (в том числе и ARM) уже хотя бы с двумя ядрами (плюс интеловский гипертрединг, дающий в два раза больше). Мегагерцы растут медленнее, чем количество ядер. Интел грезит (или грозит) приблизительно 128-256 ядер на систему уже в ближайшее время. Нужно куда-то бежать и что-то с этим делать.

Как обстоят дела в TwinCAT 3:

• Отзывчивость (Latency) меньше одной микросекунды (на тестовом Intel Core i5).
• Настраиваемый уровень предупреждений превышения уровня отзывчивости: если вероятен сильный джиттер (jitter, дрожание, отклонение) — можно задать уровень паники. Будет вылезать мутная табличка, что на этапе наладки скрасит скудность средств отладки производительности.
• Вроде бы гарантируют не превышение отведенного времени для TwinCAT. Вероятно, в случае, когда TwinCAT нагружен чересчур сильно, он перестанет отнимать время у бедного Windows. И по косвенным результатам, этому уже есть подтверждения.

Нюансы многоядерности

Задачи цифрового управления движением NC SAF и NC SVB должны быть закреплены за одним ядром. Для CNC такого ограничения нет.

Для запуска TwinCAT и Windows на одном и том же ядре в 64-х разрядной системе необходима поддержка процессором VT-x технологии. Во всех остальных случаях (AMD, старые процессоры, виртуальные машины и т. п.), придется запускать TwinCAT на отдельном ядре. Причем для TwinCAT, ядро нужно изолировать от Windows, т. е. уделить TwinCAT 100% процессорного времени.

Гипертрединг рекомендуется выключить т. к. псевдо-полу-ядра очень тесно взаимодействуют в плане блоков процессора, кеша, памяти и прочих устройств в единственном числе (физически — это по прежнему одно ядро, поэтому возможно нарушение синхронизации).

Взаимодействие ПЛК-модулей

Когда ПЛК-задачи запускаются на разных ядрах, у нас все еще остается общая память и ряд других общих ресурсов. Поэтому возможны несколько способов обмена данными: одни быстрее, другие — надежнее.

1. Маппинг данных между операционными образами.

• Доступно для всех языков.
• Гарантируется целостность данных.
• Передача выполняется синхронно с тактами задачи (пульс задачи, task pulse).

2. Указатель на область данных.

• Не гарантирует целостности данных.
• Прямой синхронный доступ из программы (данные никуда не копируются, прямой доступ к ним).

3. Вызов методов через интерфейс.

• Прямой, синхронный доступ.
• Не гарантируется целостность данных

4. Протокол ADS.

• Асинхронный и событийный способы доступа.
• Клиент-сервер.
• Вертикальное и горизонтальное применение для обмена данными.
• Доступен обмен между ядрами.
• Доступен обмен по локальной/глобальной сети (например, через TCP/IP).
• Целостность данных — гарантируется.

Ссылки и указатели

Переменные, как и ложка, не существуют. Это абстракции, освобождающие программиста от труда по управлению памятью. Нечто, называемое переменной, на самом деле всего-лишь название для ячейки памяти, в которой хранятся данные. Несмотря на это, нам по прежнему необходимо нечто противоположное — возможность поработать с памятью напрямую. В языках высокого уровня для этого существуют ссылки и указатели.

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

Указатели

POINTER TO — это указатель на переменную. Может указывать как на данные, так и на другие указатели, а также на функциональные блоки, программы, методы и функции. Не могут указывать на ссылки.

Минутка занудства: можно сделать так — POINTER TO POINTER TO POINTER TO..., но особого смысла это не имеет, а вот указатель-на-указатель иногда применяется. Например, когда необходимо переключаться между несколькими переменными или функциями.

К указателям применима арифметика: к адресу указателя можно прибавить число и наш указатель будет указывать на другую ячейку памяти, т. е. на совсем другие данные. Для этого указатели и нужны. В этом месте обычно напоминают про "отстрелить себе ногу", т. к. очень легко наприбавлять столько, что указатель будет указывать в неизвестном направлении.

Массивы — это тоже указатели, только завуалированные; и это была первая попытка человечества перестать отстреливать себе конечности, так как для массивов есть проверка на выход за границы массива.

Указатель на массив повторно разрешает членовредительство.

Чтобы подобраться ближе к данным, на которые указывает указатель, используют операцию ^  -разыменование указателя. Указатель от этого не портится и не разыменовывается, мы просто записываем данные в ту ячейку, на которую указывает указатель.

PROGRAM MAIN
VAR
    pt_a    : POINTER TO INT;
    pt_pt_a : POINTER TO POINTER TO INT;
    fbTest  : FB_Test;
    pt_fb   : POINTER TO FB_Test;

// [...]

a       := 123;
pt_a    := ADR(a);             // pt_a указывает на 'a'
pt_pt_a := ADR(pt_a);          // pt_pt_a указывает на pt_a который указывает на 'a'
pt_a^   := 67;                 // 'a' теперь равно 67

pt_fb   := ADR(fbTest);

fbTest(inp := a, in_out := a);
pt_fb^(inp := a, in_out := a); // разыменование указателя на ФБ и запуск ФБ

Ссылки

REFERENCE TO — ссылаться можно только на данные (и структуры, они тоже данные) и указатели (получим второе имя для указателя). Ссылки с арифметикой не дружат, поэтому они надежнее: выйти за границы приличия не получится.

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

PROGRAM MAIN
VAR
    a         : INT;
    ref_a     : REFERENCE TO INT;
    ref_pt_a  : REFERENCE TO POINTER TO INT;
    pt_ref_a  : POINTER TO INT;

// [...]

a         :=    123;
ref_a     REF=  a;
pt_ref_a  :=    ADR(ref_a); // указатель на ссылку
ref_a     :=    67;         // 'a' теперь равно 67
ref_a     REF=  0;          // ссылка больше ни на что не указывает
pt_ref_a^ :=    44;         // 'a' теперь равно 44

Для получения ссылки используется оператор REF=. Слитно три буквы и знак равно, все без пробелов. Это и есть оператор получения ссылки. На картинке ниже видно как переменная и ссылка на нее принимают одинаковое значение = 67:

Стоит обратить внимание на указатель pt_ref_a, который хоть и пытается указывать на ссылку ref_a, но мы то уже знаем, что ref_a это всего-лишь второе название для переменной 'a'. Поэтому в итоге указатель указывает на переменную 'a' типа INT.

После присваивания ссылке нуля (в предпоследней строке), указатель pt_ref_a по прежнему указывает на переменную 'a', хотя ссылка ref_a уже никуда не ссылается. Это подтверждает что мы просто удаляем "второе" название переменной 'а', в то время как сама переменная остается на месте (соответственно, сохраняется и указатель на нее).

Зачем ссылки?

Предположим, мы хотим передать в ФБ переменную, которую ФБ обработает, а затем запишет в эту переменную новое значение (так часто поступают со структурами, когда хотят заполнить их интересными данными или нулями). Проще всего это можно сделать передав указатель на переменную, но тогда возникает опасность, что внутри себя ФБ воспользуется арифметикой указателей и сдвинет указатель настолько, что в итоге обратится к запрещенному и обрушит всю систему. Что делать?

Давайте воспользуемся ссылкой, ведь для нее арифметика не работает! Все правильно, и за нас это уже сделали.

Любой ФБ, кроме входных параметров VAR_INPUT и VAR_OUTPUT имеет набор VAR_IN_OUT. Если первые два принимают входные данные по значению, то последний IN_OUT принимает входной параметр как ссылку. Изменяя ее значение внутри ФБ, мы сможем изменять значение переменной снаружи ФБ, ведь ссылка это второе имя переменной.

FUNCTION_BLOCK FB_Test
VAR_INPUT
    inp    : INT;

VAR_OUTPUT
    out    : INT;

VAR_IN_OUT
    in_out : INT;

// [...]

inp    := 44;
out    := 55;
in_out    := 77;

Запускаем и смотрим в отладчике на результат:

ФБ изнутри изменил значение внешней переменной 'a', сменив ее значение на = 77. Изменение входного параметра inp внутри ФБ на = 44, никак не повлияло на значение переменной 'a', так как он принимает параметр по значению (просто создает локальную копию значения).

Массивы переменной длины

Мы разрабатываем ФБ, который как-то там должен изменять содержимое массива (например, заполнять латинскими лорем-ипсумами или нулями). Внимание, вопрос — как передавать в ФБ массивы разной длины?

FUNCTION_BLOCK POUPIUPOW
VAR_IN_OUT
    VarArray : ARRAY [*] OF INT;
END_VAR
VAR
    start    : DINT;
    end      : DINT;
END_VAR

// [...]

start := LOWER_BOUND(VarArray, 1);
end   := UPPER_BOUND(VarArray, 1);

Работает только для VAR_IN_OUT параметров (иначе как бы мы влияли на внешние к ФБ массивы).

Совместимо с третьей редакцией стандарта МЭК.

Для определения габаритов или просто начала и конца массива используются функции LOWER_BOUND и UPPER_BOUND. Второй параметр этих функций — это номер размерности: 1 — получить длину одномерного массива; 1..2 — длину строки или кол-во столбцов для двумерного массива; 1..3 — длина строки, столбца или глубины для 3D массива.