Мы замкнули шину K-Bus

Чтобы проверить информацию из истории про K-Bus-Interbus, коллега А по моей просьбе взял BK9050, подключил к нему модуль дискретных входов-выходов KL1859... и не стал подключать терминальный модуль.

Все испытания проводились в целях испытания. Ни один из модулей не пострадал. Животные участие не принимали.
Не пытайтесь повторить, потеряете гарантию!

Сканируем… Устройства на шине недоступны. Проверяем индикацию коплера. На картинке выше виден единственный красный индикатор. Документация говорит, что это "K-Bus ERR", то есть ошибка шины K-Bus. В данном случае отсутствует терминальный модуль.

Вспоминаем результаты препарации из предыдущей статьи и замыкаем шину:

Все индикаторы зеленые, шина доступна, устройства сканируются и обнаруживаются. Никогда не делайте так в реальных условиях! Всегда используйте терминальный модуль KL9010. 

Компактные сервомодули ELM72xx

Линейка сервотерминалов расширилась до 16 ампер. ELM72xx предлагает прикоснуться к блестящему металическому корпусу компактного сервотерминала.

Изображение: Beckhoff Automation

Сервотерминалы устанавливаются на дин-рейке вместе с другими EtherCAT терминалами в общей линейке. Металлический корпус лучше рассеивает тепло. Кабели подключаются через разъемы: должно быть удобнее.

• ELM7211 — 1 двигатель до 4.5 A (I_rms).
• ELM7212 — 2 канала по 4.5 A (I_rms).
• ELM7221 — один на 8 A (I_rms).
• ELM7222 — два по 8 A (I_rms).
• ELM7231 — тот самый единственный на 16 A (I_rms).

Модули расчитаны на двигатели AM8100. Питание 48 вольт; 24В на половине мощности. Питание и обратная связь в одном кабеле — однокабельная технология. Можно подключить внешний тормоз, обратную связь (энкодер или резольвер) и внешний тормозной резистор. Цифровые входа поддерживают функцию Probe Unit.

TwinSAFE логика обеспечивает безопасность через простые функции STO/SS1 (Safe Torque Off / Safe Stop 1) поверх EtherCAT (FSoE, Safety over EtherCAT) или в рамках комплекса безопасности движения Safe Motion (IEC 61800-5-2 / ГОСТ Р МЭК 61800-5-2-2015).

Остается вопрос о рассеивании тепла: нужны ли опциональные вентиляторы для обдува блестящего металлического зада?

Переменная через указатель, через ADS

Значение переменной можно прочитать через указатель по ADS.

PROGRAM MAIN
VAR
    state:  UINT;
    pState: POINTER TO UINT;
END_VAR

pState := ADR(state);

Прочитаем значение переменной `state` через ее указатель `pState`. Нужно разыменовать указатель, добавив спец. символ `^` к имени указателя. Получим `pState^`. Программа на C# для текущей версии 4.4.10 библиотеки Beckhoff.TwinCAT.Ads:

ushort state = (ushort) tcAdsClient.ReadSymbol( "MAIN.pState^", typeof( ushort ), false );

Значение переменной читается. Теперь возьмем пробную версию новой библиотеки 5.0.1-preview.12 под .NET Core 3.1.0. Код поподробнее:

Программа читает переменную и в зависимости от ее значения рисует замысловатые узоры. Имея указатель можно вытягивать значение переменной. Это полезное свойство и дополнительные телодвижения здесь не нужны.

Для новой библиотеки под .NET Core требуется создать файл роутинга `StaticRoutes.xml`. В этом файле настраиваются соединения между целевым контроллером и ПК. Если контроллер  и ПК находятся на одной и той же машине, то настраивать этот файл не нужно. Можно просто удалить его.

Атрибут TcNcAxis

Атрибут TcNcAxis линкует NC ось со стороны кода, автоматически изменяя конфигурацию ПЛК. Про этот атрибут уже было в символьной линковке через атрибуты. Здесь же будет пара-тройка нюансов.

Массивы

Большое количество осей удобно объединять в массивы. Массив осей можно линковать одним атрибутом:

{attribute 'TcNcAxis' := '[1]:=Axis X; [2]:=Axis Y; [3]:=Axis Z' }
axes: ARRAY [1..3] OF AXIS_REF;

В имени оси можно использовать пробел. Имя оси в атрибуте тоже записывается с пробелами. Количество пробелов должно совпадать и между буквами в имени, и в атрибуте. Axis⎵X и Axis⎵⎵X — это разные оси.

Если имя оси указано в атрибуте, но оси с таким именем нет, то в конфигурации будет создана новая ось.

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

Автомапинг функциональных блоков

Если нет доступа к внутренностям функционального блока, можно воспользоваться… атрибутом:

{attribute 'TcNcAxis' := '.axisZ:=Axis Z'}
fbFoobar: FB_Foobar;

[...]

FUNCTION_BLOCK FB_Foobar
VAR
    axisZ: AXIS_REF;
END_VAR

[...]

В одном программном блоке может быть несколько экземпляров функционального блока. Но можно слинковать оси только одного экземпляра ФБ. Нельзя линковать несколько переменных AXIS_REF с одной и той же осью. При компиляции система выдаст ошибку: 

Mapping conflict! Same data of 'TINC^NC-Task 1 SAF^Axes^Axis Z^Inputs^FromPlc' is written from different sources

Секретный сервис 700

Не все сервисы TwinCAT описаны в документации. В старых исходниках библиотеки AdsClient, в файле AdsSpecial.cs, есть любопытная функция public string GetTargetDesc(). Описание функции гласит: "Get an xml description of the plc...". Посмотрим, какое именно описание отдаст нам контроллер.

Начнем с системного сервиса, порт номер R3_CTRLPROG = 10000. Официальное описание списка функций заканчивается номером 600 (см. таблицу System Service Index Groups). Мы же прочитаем индекс 700 (0x02BC_hex). Настраиваем роутинг и начинаем читать. Код C# программы:

 

Первый запрос отправляем с параметром typeof(int). Где-то внутри библиотеки это транслируется в параметр команды равный 4 — это длина типа данных int в байтах. В ответ, запрос вернет длину XML текста с описанием устройства. Зная размер, мы отправляем второй запрос в тот же порт-индекс-смещение, но в качестве параметра передаем длину описания, полученного на предыдущем шаге. Результат парсим. С помощью LINQ ищем и вытаскиваем интересующие нас поля описания.

Контроллер CX9020 вернул такой XML:

 

Сравним описания от CX9020 (Win CE) и ноутбука (Windows 10). Чтобы отследить различия, сохраним XML в отдельный файл: xdoc.Save( "cx9020.xml" ); и воспользуемся программой WinMerge:

TС/BSD

Новая, перспективная и все еще недоступная операционная система выдает следующее описание:

 

Пропали элементы `ImageDevice`, `ImageLevel`. Значение `CPUArchitecture` стало более осмысленным, но что такое 9 все еще непонятно.

Тоже сервисы

Можно найти еще несколько интересных сервисов, если копнуть глубже. Для раскопок пригодится какой-нибудь HEX-вьюер (VSCode hexdump) и следующая строка: File.WriteAllBytes( $"idx_{READDEVDESCRIPTION_IDX}.bin", adsStream.ToArray() ); // Начинайте копать.

Индекс 701 выдаст список всех сетевых интерфейсов доступных на устройстве. IP-адреса, маски подсети и что-то еще. Формат неизвестен, но можно разобраться самостоятельно. Копайте.

Из любопытного, для TC/BSD сервис возвращает название сетевого интерфейса в юникс стиле — `em0`.
А для Windows возвращает GUID: "{7D8FDCBA-6250-8DFF-4089-AB0845B12EDC} Qualcomm Atheros AR5BWB222 Wireless Network Adapter 192.168.2.177 255.255.255.0".

Индекс 702 отдает имя целевой машины: PC-8E5B1A, CX-3F5BC9... Строка заканчивается '\0', не забывайте про .TrimEnd('\0'); Продолжайте копать.

Агент данных OPC UA

Настроим агент данных на трансляцию данных из OPC UA сервера. Одновременно оставим без изменения трансляцию из ADS переменных. Пусть ADS работает параллельно с OPC UA. Активируйте конфигурацию каждый раз, когда изменяете что-либо в схеме агента. Он перезапустится с новой схемой автоматически.

ПКМ по пустому месту → Add Gate (OpcUaDevice). В окне `Properties` ввести в поле`Url` адрес своего OPC UA сервера: opc.tcp://192.168.1.100:4840. Добавьте канал подписчика: Add Channel (Subscriber), стрелка вниз 🡇.

Теперь открываем окно `Target Browser`, закладка `OpcUa`, добавляем OPC UA сервер контроллера, выбираем необходимые объекты-переменные и тащим их на "подписчика".

Возможно понадобится донастроить переменные подписчика. В моем случае Агент добавил мусор в имя переменной ns=4;s=MAIN.nCounter. Исправляется в окне `Properties`, поле `URN` и превращается в MAIN.nCounter. Ниже в примере исправлена только одна переменная-символ:

>>> {"Timestamp":"2020-11-06T11:48:08.151","GroupName":"_MQTT Broker_28","MAIN.nCounter":-1946,"ns=4;s=MAIN.rCounter":784486.0}
>>> {"Timestamp":"2020-11-06T11:48:09.150","GroupName":"_MQTT Broker_28","MAIN.nCounter":-1846,"ns=4;s=MAIN.rCounter":784586.0}
>>> {"Timestamp":"2020-11-06T11:48:10.150","GroupName":"_MQTT Broker_28","MAIN.nCounter":-1746,"ns=4;s=MAIN.rCounter":784686.0}

Начало работы с агентом данных

Агент позволяет передавать переменные программы и другие данные из одного места в другое. Например, есть группа контроллеров CX8090. На отдельном ПК устанавливается TC3 IoT Data Agent. Он настраивается на проброс данных через интернет на сервер-брокер MQTT. Из брокера данные забираются в базу данных. Позже аналитики анализируют, а сервисный отдел мониторит и бдит. Версия TwinCAT, разрядность и тип процессора, древность контроллеров — все это не важно. Переменные из контроллера можно передавать куда угодно, в обе стороны.

Изображение: Beckhoff Automation

Современные протоколы типа MQTT–AMQTT–RabbitMQ не требуют входящего подключения. Агент и контроллеры могут находится за NAT, файерволом или другой сетевой инфраструктурой. IP-адрес может быть серым и динамическим, но подключение к брокеру всегда исходящее. Поэтому переменные контроллера легко отдавать и легко забирать. В обе стороны.

Лицензии

Для ПК, на котором установливается Агент, необходимы минимум две лицензии: TC1000 | TC3 ADS и TF6720 | TC3 IoT Data Agent. Доступна пробная лицензия на 7 дней.

Лицензирование основано на группах порталов. Порталы объединяются в пакеты (Gate packs). Порталом называют одно подключение. Например, подключение к устройству через ADS или OPC UA. Лицензия TF6720 обеспечивает работу с четырьмя порталами. Большее количество порталов можно получить после покупки дополнительных лицензий (TF6721-TF6724). Количество порталов складываются: TF6720 + TF6721 = 8 порталов.

Принципы работы

Open local, Save local работают со схемой в локальной конфигурации Агента C:\TwinCAT\3.1\Boot\TcIotDataAgentConfig.xml. Эта схема будет использована при старте Агента на этом локальном ПК. Во время работы рядом будет лежать лог TcIotDataAgent.log. По нему можно проводить диагностику работы Агента.

Open file, Save file импорт/экспорт схемы из отдельного файла.

С помощью кнопки "активировать конфигурацию", можно активировать схему на удаленном контроллере. На кнопке изображена традиционная горка кубиков (Save to selected target and activate).

В окне `Topology` создаем схему передачи данных. Нужно запомнить два простых принципа: создаем правой кнопкой мыши (ПКМ), а затем соединяем элементы с помощью Ctrl + тащим и бросаем. Например:

• ПКМ по пустому месту → Add Gate (ADS) → получился круг — это ADS-портал, ведущий к переменным контроллера.
• Затем, ПКМ → Add Gate (MQTT) → появилось облако — это брокер MQTT, источник данных.
• ПКМ ADS портал → Add Channel (Subscriber) → создается подписчик (subscriber) в виде прямоугольника. Стрелка вниз 🡇 указывает направление подключения.
• ПКМ Подписчик → Add Symbol → добавляется новая переменная (symbol) для чтения из контроллера. Можно сделать проще: открыть окно `Target Browser`, перетащить и бросить переменную на "подписчика".

Схему можно создавать и редактировать через другие окна программы. Исследуйте их. Выберите удобный способ работы с программой.

Аналогично поступаем с порталом MQTT Broker, где вместо `Add Gate` доступен `Add Channel`. Брокер работает не с переменными, а с каналами. Через них идут потоки переменных.

Дальше тащим прямоугольник подписчика ADS: Ctrl + левая клавиша мыши (ЛКМ). Бросаем его на прямоугольник канала MQTT. Между элементами появляются связи.

Настройки всех элементов собраны в окне `Properties`.

Пример программы

Необходимо проработать четыре момента:

• ПЛК программу как источник данных. Подойдет любая версия TwinCAT. Я брал как вторую, так и третью версию TwinCAT. Меняется номер порта ADS 801 → 851, но принципы создания схемы остается прежним.
• Создать схему передачи данных для Агента.
• Выбрать MQTT брокер данных.
• Создать клиента для брокера MQTT. Я напишу простую программу на C#. Она будет читать данные из брокера. Здесь можно воспользоваться готовыми клиентами MQTT и запустить их на смартфоне.

ПЛК программа примитивная:

PROGRAM MAIN
VAR
    iCount: INT;
    rCount: REAL;
END_VAR

iCount := iCount + 1;
rCount := rCount + 0.1;

Схема Агента

Пора выбрать бесплатного брокера на тестирование. Мне понравился HiveMQ. Кроме него проверил Mosquitto. Он работал, но значительно медленнее.

Пришло время создать схему:

Разбивка по каналам позволяет устанавливать единые сетевые настройки для нескольких переменных сразу. Можно создать один единственный канал и транслировать в нем сразу несколько переменных. Чтобы было интереснее, я разбил трансляцию от брокера на два канала (см. картинку выше, правая часть):

• Ads_Mqtt_11_19 — транслирует переменную MAIN.rCount;
• Ads_Mqtt_11_17 — передает целое число из переменной MAIN.iCount.

Внутри канала данные брокера можно раскидать по темам (Topic). Это настраивается в окне `Properties`. Например, пусть `rCount` как бы передается из жилой комнаты GOT/TWINCAT/ROOM, а переменная `iCount` приходит из офиса GOT/TWINCAT/OFFICE. В клиенте брокера я смогу выбрать или одну конкретную, интересующую меня тему, или сразу несколько тем. Темы фильтруются с помощью спец. символов `*`, `?` или `#`. Например, я хочу в одном канале получать данные ROOM+OFFICE: GOT/TWINCAT/#.

Клиент брокера

Для C# я использовал библиотеку MQTTnet. Она легко устанавливается из NuGet. Раскомментируйте строку и подставьте название своего топика-комнаты в константу `MQTT_TOPIC`.

 

Результат работы клиента:

Одновременно я установил на телефон бесплатный клиент `MQTT Dash` и он также смог отображать данные с ПЛК. Трансляция идет через интернет, можно сходить на обед и одним глазом посматривать как контроллер продолжает работать:

Функции измерения нагрузки ПЛК

Измерение загрузки контроллера можно условно разделить на:

• измерение нагрузки процессора. Показывает справляется ли вся система в целом: Windows + TwinCAT.
• Измерение времени исполнения программы в текущем цикле. Укладывается ли текущая ветвь программы в заданное время цикла.
• Профилирование. Замер времени выполнения отдельных частей программы.

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

Разбор программы

В программе выше используются функции: TC_SysLatency, TC_CpuUsage, GETCPUCOUNTER. Также используется информация из встроенного глобального массива SystemTaskInfoArr[]. Он предоставляет структуру данных SYSTEMTASKINFOTYPE.

TC_SysLatency пропустим, я по прежнему не вижу в нем смысла. TC_CpuUsage возвращает целое число процентов нагрузки на процессор. Это значение должно совпадать с графиком в System Manager, но это не точно и это было видно выше.

GETCPUCOUNTER работает независимо от счетчика в CPU. Это счетчик 100 наносекундных циклов. Увеличение на единицу соответствует прошедшему времени в 100 нс. Увеличение на 10 соответствует 1 микросекунде. Посмотрим как перевести в миллисекунды с десятичными долями:

52'108'000 наносекунд = 52'108'0 100*нс = 52'108 микросекунд = 52,108 миллисекунд.

LREAL cpuCntMs := (cpuCntLoDW + cpuCntHiDW) / 10000.0

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

SystemTaskInfoArr[] в том же цикле отдает структуру SYSTEMTASKINFOTYPE. Индексом для массива служит номер текущей задачи. Индекс можно получить с помощью функции GETCURTASKINDEX в этом же цикле и начать его использовать уже в следующей строке программы.

Структура SYSTEMTASKINFOTYPE содержит состояние предыдущего цикла. Эта структура содержит:

• cycleTimeExceeded — TRUE = время цикла превышено, FALSE = время выполнения в норме. Значение параметра не фиксируется, в каждом цикле оно может быть разным. Всё зависит от времени исполнения предыдущего цикла.
• cycleTime — максимально возможное время на выполнение цикла. Задается в сотнях наносекунд. Для перевода в миллисекунды, разделите значение cycleTime на 10000.0.
• lastExecTime — время выполнения программы в предыдущем цикле. Предыдущего, потому что текущий цикл еще только выполняется, вот прямо сейчас, в данный момент. Значение в сотнях наносекунд.
• cycleCount — номер текущего цикла от момента включения контроллера. Если номер цикла умножить на длительность цикла cycleTime, можно узнать сколько прошло времени с момента включения контроллера.

 

В TwinCAT 3 массив поменял имя на _TaskInfo[], а структура стала более подробной и теперь называется PlcTaskSystemInfo.

Нагрузка процессора CX8090

Измерять производительность — это хороший способ знать, что осталось за кадром. Правда иногда это просто любопытство. В случае с бюджетным CX8090, все немного тяжелее, и не только по причине слабого процессора частотой в 400 МГц. Кстати, на подходе CX7000, и там будет целых 480 МГц, новый ARM Cortex™-M7 против старого ARM9.

При первом подключении к CX8090, мы видим постоянную загрузку процессора в 10%. Так сделано специально — измерение нагрузки добавляет нагрузку на процессор. Внезапно, эта тема обозрена в статье справочной системы CPU load. Не стоит пренебрегать таким полезным ресурсом, и вообще полезно гуглить, ведь так удобнее искать.

В рабочем режиме измерение лучше отключить, лишняя нагрузка не нужна. И наоборот — на этапе отладки полезно включить. Для этого необходимо запустить редактор реестра: Start → Run... → regedit. И внести изменения в один ключ: HKLM/SOFTWARE/BECKHOFF/TWINCAT/RTime/EnableRTimeMeasurement. 0 = отключено, 1 = включено. Замеры производятся раз в 10 миллисекунд. Точность замеров нагрузки не гарантируется, если циклы задач длиннее 10 мс.

И здесь пост должен был закончиться… посмотрим, как будет вести себя нагрузка, если время цикла увеличить с 10 мс до 50 мс. Просто увеличим время цикла в пять раз.

При реальной нагрузке приблизительно в 30-33% график плющит и колбасит от нуля до реального значения. Кстати, чтобы работал нижний график System Latency, его нужно включить в реестре. Рядом с параметром EnableRTimeMeasurement лежит параметр EnableLatencyMeasurement; 1 = работает, 0 = отключено.

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

В результате получил ровный, красный график нагрузки на процессор. Latency выведен зря, никакой пользы я от него не нашел.

Превышаем лимит нагрузки

Превысим нагрузку процессора и начнем с графика, показывающего времени цикла:

Время цикла по прежнему 50 мс. На графике уставлен потолок в 60 мс, чтобы график было видно. Потолок устанавливается правой кнопкой мыши, Settings…

Значение Total показывает 52,108 мс, что на 2 мс больше лимита времени цикла. Здесь же начинает увеличиваться счетчик превышения лимита Exceed counter. Все очень плохо. Посмотрим на график нагрузки процессора. Сначала системный, затем программный:

Когда значения не совпадают

Результат на графиках выше вполне ожидаемый, но(!) так бывает не всегда. На следующих трех графиках время цикла находится в допустимых пределах, а нагрузка процессора якобы превышена. Что происходит на самом деле понять трудно.

Выводы

Стоит обратить внимание на примечания в справочной системе. Графики времени цикла и нагрузки на процессор нужно анализировать по отдельности. Показания нагрузки на процессор строится как-то хитро, даже при времени цикла ≤10мс. Например, при трехкратном превышении времени цикла можно получить нагрузку на процессор в 56%. Это некорректное показания. Значит для тонкой настройки ПЛК желательно использовать программный способ. Все это относится конкретно к CX8090 и TwinCAT 2.

Разбор программы для измерения и краткое описание функций будет отдельным постом чуть позже.

Блоки питания Бекхофф

В прайсе Бекхоффа появились блоки питания. Официальное описание находится в разделе ввода-вывода:
beckhoff.com → Products → I/O → Power supplies.

Изображение: Beckhoff Automation

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

• PS1000 — небольшие решения (2,5–20 ампер).
• PS2000 — стандартные решения (5–20 ампер).
• PS3000 — повышенная нагрузка (10–40 ампер).

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

1 фазное напряжение

Номинальное входное напряжение — переменное 100..240 вольт. Допускается диапазон 85..264 В. Предельный диапазон от 80 до 300 вольт может использоваться только при плохих входных линиях питания и при прочих просадках-выбросах. Максимально допустимое входное напряжение может достигать 300 вольт, но не дольше 500 миллисекунд.

На старте рабочего режима предусмотрен гистерезис: блок питания включается при 80 вольтах на входе и отключается при 70 В.

3 фазное напряжение

Номинальное входное напряжение — 3 фазное, переменное 380..480 вольт. Допускается диапазон 323..576 В. На старте рабочего режима предусмотрен гистерезис: блок питания включается при 305 вольтах на входе и отключается при 275 В. При включении происходит задержка номинального напряжения на выходе в 500 / 600 мс. Зависит от входного напряжение 400 / 480 В.

Выход `DC-OK`

Релейный контакт `DC-OK` работает также как индикатор `DC-OK LED`. Контакт отражает состояние питания на выходе блока питания.

• Контакт замыкается, когда выходное напряжение достигает 90% уставки.
• Контакт размыкается, когда выходное напряжение проседает ниже 90% уставки.
• Игнорируются просадки напряжения короче 1 миллисекунды. Контакт остается замкнутым.
• Просадки длиннее 1 миллисекунды размыкают контакт на 250 миллисекунд.

Вход выключения (Shut-down Input)

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

Вход способен работать в трех режимах:

• Перемычка. Замыкает контакты, когда необходимо отключить питание. В рабочем режиме перемычка отсутствует, то есть разомкнута. Сюда подойдет кнопка или реле.
• Открытый коллектор. Управление током.
• Внешнее питание. Рабочий режим, когда на контактах отключения больше 4 вольт. Выход БП отключается, когда напряжение на контактах падает ниже 1 вольта.

Объединение нескольких БП

Обязательно использовать полностью идентичные модели блоков питания.

Объединение блоков питания ухудшает параметры выходного тока: ток утечки, эл-магнитные наводки, пусковой ток, гармоники, и тому подобное.

Общая рекомендация: не объединять несколько БП.

Последовательное подключение

Повышаем выходное напряжение. Можно соединять несколько БП вплоть до 150В. Начиная с 60 В требуется повышенная осторожность и соблюдение мер безопасности. Не допускать обратного напряжения в генераторных режимах (ЭДС самоиндукции, return voltage immunity, Back-E.M.F.).

Параллельное подключение

Получаем большую мощность, то есть больший максимальный ток. Можно резервировать блоки питания, разделяя между ними нагрузку. Схемы резервирования 1+1 или N+1. Оба варианта требует включения диодных сборок или других буферных устройств.

Рекомендуется оставить заводские настройки для всех БП или согласовать выходное напряжение с точностью ±100 милливольт. Читайте инструкцию!

По умолчанию в блоке питания установлен одиночный режим (Single Use). БП работает в одиночном режиме, если джампер или переключатель `Parallel Use` отсутствуют.

В параллельном режиме (Parallel Mode) блок питания допускает разброс выходного напряжения до 2,5 вольт. В одиночном режиме разброс меньше, он равен 100 милливольтам. Характеристика жестче в одиночном режиме и мягче в параллельном режиме. На холостом ходу в параллельном режиме выходное напряжение на 4% больше напряжения при номинальной нагрузке. Так сделано для лучшей балансировки блоков питания между собой.

Сокеты не реального времени

Из ПЛК задачи можно сделать TCP/UDP клиент или даже сервер. Это позволяет работать с данными современной периферии без разработки промежуточных слоев. У нас есть выбор между TF6310 (обычная и давно практикуемая) и TF6311 (модная, современная, риалтаймовая). Обе-две работают как на PC/CX (x86), так и на CX (ARM). В этом посте будет практика работы с обычной библиотекой 6310, а с новой разберемся как-нибудь позже.

Изображение: Beckhoff Automation

TF6311 TCP/UDP (realtime)

Полное описание доступно в инфосисе. Обе библиотеки доступны из ПЛК задачи, но 6311 работает "рядом" с ядром TwinCAT 3, на том же системном уровне.

Здесь заострю внимание на особенностях, плюсах и минусах.

• Только TwinCAT 3.
• Функционал не требует установки, все компоненты уже встроены в TwinCAT 3.
• Требуется лицензия TC3 TCP/UDP RT.
• Есть возможность использовать временную (trial) лицензию на время разработки.
• Работает напрямую с сетевой картой, минуя большинство механизмов операционной системы.
• TF6311 настраивается в проекте через TCP/UDP RT TcCom Parameter. Это требует отдельного рассмотрения.

Минусы

• Не рассчитан на большие и незнакомые сети. Вероятно подразумевается интернет, либо большой интранет.
• Не для больших объемов данных.
• Не поддерживает мультикаст в UDP.
• Windows Compact CE только начиная с версии 7.
• Windows Firewall отсутствует в цепочке передачи пакетов (менее защищенные соединения).
• Только TwinCAT-совместимые карты. Список доступен в Supported Network Controller by Beckhoff Ethernet Driver.
• Нет связи с локальным, стандартным сетевым интерфейсом Windows. Можно реализовать через стороннего посредника.
• Сетевые коммутаторы (эзернет свичи) EL6601 и EL6614 не могут использоваться совместно с этой библиотекой.

Плюсы

• Очень детерминированный и предсказуем (подтвердить не могу).
• Поддержка С++ (похоже, что это основное назначение библиотеки).
• Поддерживает ARP/Ping.

TF6310 TCP/IP

Работает через специальный ADS-сервер, а дальше через стандартный WinSock, по сути копируя стандартный функционал сетевого ввода-вывода. Как и что устанавливать вменяемо описано в справке, и проблем это обычно не вызывает.

Для TwinCAT 2 мы устанавливаем TS6310. Он приносит с собой следующие библиотеки в каталог TwinCAT\Plc\Lib:

• TcpIp.lib — базовые функции TCP/IP и UDP;
• TcSocketHelper.lib — вспомогательные функции TCP/IP, упрощающие жизнь разработчика. Содержит готовые ФБ с полным циклом клиент-сервер и сервер-клиент.
• TcSnmp.lib — протокол SNMPv1, вспомогательные функции.
• TwinCAT TCP/IP Connection Server — по сути это мост ADS ↔ TCP/IP.

Практика 6310

TCP-клиент рассчитан на передачу больших объемов данных в виде непрерывных потоков. Данные текут непрерывно, но ничто не мешает разбить их на пакеты. Перед началом работы устанавливается соединения, которое по окончании работы разрывается. Длительность передачи данных после соединения не оговаривается: минуты, часы, дни, года. Так было задумано и это обычная практика работы с TCP/IP протоколом.

Минимальная реализация TCP-клиента:

• FB_SocketConnect и FB_SocketClose — для подключения и разрыва сессии.
• FB_ClientServerConnection — включает в себя оба предыдущих блока и упрощает работу с ними.
• FB_SocketSend и/или FB_SocketReceive — для обмена данными.

Минимальная реализация TCP-сервера:

• FB_SocketListen — открывает сокет на прослушивание в режиме ожидания клиента.
• FB_SocketAccept и FB_SocketClose — открывают и соответственно закрывают соединение.
• FB_ServerClientConnection — умеет все вышеперечисленное вместе и упрощает работу.
• FB_SocketSend и/или FB_SocketReceive — для обмена данными.

UDP-клиент пакетный, работает без установки постоянного соединения: отправил пакет данных и забыл. Пакет может и не дойти, а может дойти фрагментированным, то есть разбитым на несколько частей. Иногда задняя часть может придти раньше передней (если ползли разными маршрутами). И так тоже было задумано, во славу производительности.

Минимальная реализация UDP-клиента:

• FB_SocketUdpCreate и FB_SocketClose — открыть/закрыть сокет.
• FB_SocketUdpSendTo и/или FB_SocketUdpReceiveFrom — прием-отправка данных.

Для UDP-пакета ограничен максимальный размер отправляемых данных. По умолчанию он равен 8192 байт (это число задается константой TCPADS_MAXUDP_BUFFSIZE). Поэтому стоит обратить внимание на аргумент cbLen функции FB_SocketUdpSendTo. Ограничение служит для экономии памяти.

Для всех типов связи FB_SocketCloseAll закрыть всё открытое и закончить любые работы в пределах текущего рантайма. Это который имеет определенный порт, например, 801 для первого рантайма TwinCAT 2.

FB_SocketAccept, FB_SocketReceive, FB_SocketUdpReceiveFrom — вызываются циклически (polling), то есть каждый цикл. Остальные блоки вызываются по мере необходимости.

Производительность

TwinCAT 2

CX8090 (TC2, WinCE 7, ARMv4) — идеально когда происходит один вызов сетевой функции за цикл. 4 соединения за цикл работают нормально, при большем числе идут таймауты.

CX9020 (TC2, WinCE 7, Arm Cortex™-A8) — 4 соединения одновременно за цикл работают нормально, а дальше идут таймауты. Соединения-подключения все равно необходимо выполнять последовательно: сначала устанавливается одно соединение и только затем выполняем следующее подключение.

TwinCAT 3

CX8190 (TC3, WinCE 7, ARM Cortex™-A9) — 10 соединений одновременно за цикл работают нормально. Соединения-подключения необходимо выполнять последовательно.

CX2030 (TC3, Windows 7 Emb Std, Core-i7) — 10 соединений одновременно за цикл работают нормально. Соединения-подключения необходимо выполнять последовательно.

Не больше 10 клиентов

• Не больше 10 клиентов. Ограничение в 10 клиентских подключений на рантайм, а возможно и на весь ПЛК, но это не точно.
• Разные циклы — разные подключения. Открывать соединение лучше друг за другом по одному за цикл.
• Функции всегда работают как минимум один цикл. После первого вызова, в последующих циклах можно спокойно вызывать ФБ с bExecute := FALSE, ожидая когда функция переключится в NOT bBusy, что означает поступление данных либо ошибку.
• При обрыве связи возвращает bError = FALSE и nRecByte = 0. Для определения обрыва необходимо самостоятельно использовать собственный таймер для контроля таймаута. Великая вещь, что функции здесь неблокирующие (разработчики на C++ и другие поймут).
• Протокол поточный, если читаете данные пачками, то полученные данные необходимо накапливать в буфере, десериализовать или просто сканировать этот буфер на предмет специального тэга или какой-либо другой ситуации предусмотренной протоколом (это уже зависит от специфики протокола).

Мне стало интересно откуда это волшебное и круглое десятичное число — десять. И почему нельзя взять и подключаться ко всему и сразу. Я начал следить за количеством соединений и количеством системных потоков (threads).

Соединения - потоки
 2 - 8
 3 - 10
 4 - 12
 . . ..
 6 - 16

Просматривается явная зависимость — на каждое новое соединение создается два новых потока. Зачем два? Заглянем в лог TcpIpServer.log:

Видно, что сначала создается ADS-сокет CTcpAdsSocket::CTcpAdsSocket(); Он будет принимать команды и данные из ФБ ПЛК-задачи, а затем создается требуемый TCP-сокет CTcpSocket::Create(); теперь уже для непосредственной передачи данных. Поэтому каждый цикл можно открыть только одно новое соединение — на запрос создания сокета создается только одна связка ADS ↔ TCP|UDP. Такая вот архитектура, упрощенно.

Не больше 10, но можно меньше

Под Windows CE можно поиграть с ключами реестра: Start → Run... → regedit. Создать ключ Registry → New → Key: HKLM\SOFTWARE\Beckhoff\TwinCAT TcpIp Server. Внутри раздела доступны несколько значений-параметров типа DWORD. Что удалось выяснить:

MaxTcpSocketCount

0 = вероятно стандартные 10 сокетов-соединений.

1 = запретить вообще все подключения. Теперь функции FB_SocketListen и FB_SocketConnect возвращают код ошибки TCPADSERROR_NOMOREENTRIES (0x0000800132769).

2 = 1 доступное подключение.

3 = 2 доступных подключения.

[...]

11 = 10 максимально доступных подключений. Всё, больше нельзя.

MaxUdpSocketCount — аналогично MaxTcpSocketCount, но для UDP протокола.

AdsServerCommTimeout — возможно таймаут ADS-сервера. Единицы измерения вероятно миллисекунды.

DisableKeepAlive — запретить постоянные KeepAlive подключения?

ThreadPriority — приоритет системного потока? Значения не известны.

LogLevel

0 = отключен.

1 = включен. Логировать будет сюда: \Hard Disk\TwinCAT\TcpIpServer.log

TcSocketHelper

TcSocketHelper.lib выполняет за нас все трудоемкие операции по клиентским подключениям к серверу и в обратную сторону — отслеживает клиентские подключения к серверу. Доступные примеры лежат в справочной системе.

FB_ServerClientConnection — выполняет функции TCP-сервера. Внутри себя содержит и выполняет FB_SocketListen, FB_SocketAccept и FB_SocketClose. На выходе выдает идентификатор сокета hSocket для подключившегося клиента. Дальше передаем его в FB_SocketSend и/или FB_SocketReceive.

FB_ClientServerConnection и FB_ConnectionlessSocket — первый служит для создания TCP-клиентов, а второй для UDP. Оба умеют создавать и закрывать соединения. При успешном соединении выдают на выходе hSocket для передачи в FB_SocketSend и/или FB_SocketReceive.

Из интересного все функции, связанные с получением данных (Receive), внутри себя содержат механизм регулировки скорости обновления ФБ (пропуск тактов, троттлинг, throttling). Ничего особенного, это обычный подход в такой ситуации. Кратко выглядит так:

TYPE T_ThrottleTimes: ARRAY[0..MAX_THROTTLE_MODE] OF TIME;
END_TYPE

throttleTimes: T_ThrottleTimes := T#0s, T#10ms, T#20ms, T#40ms, T#60ms, T#80ms, T#100ms,
                                  T#200ms, T#400ms, T#600ms, T#800ms, T#1s, T#2s;

И скрытая, только для внутреннего использования, функция-обертка над таймером FB_ThrottleTimer, которая состоит всего-лишь из одной строки с вызовом таймера:

timer(
    IN := bIn,
    PT := throttleTimes[LIMIT(0, selector, MAX_THROTTLE_MODE)],
    Q  => bOut,
    ET => tElapsed );

Здесь `selector` задает текущий режим, а его значение изменяется через вызов одного из четыре экшенов (Action):

• MaxSpeed — selector = 0.
• MinSpeed — selector = MAX_THROTTLE_MODE.
• SlowDown — увеличивает задержку, уменьшает скорость опроса.
• SpeedUp — уменьшает задержку, увеличивает скорость опроса.

Суть этого действа в автоматическом регулировании интервал ожидания: увеличивать интервал если сообщений нет, и снижать интервал ожидания, если сообщения пошли часто-часто.

Управление битовыми полями

В TwinCAT 3 появился тип данных BIT. Он предназначен искючительно для создания новых типов данных с точно заданной структурой и удобного обмена данными с периферией (железом). Применять его можно только при объявлении новых структур данных:

TYPE BitBang :
STRUCT
    b0: BIT;
    b1: BIT;
    b2: BIT;
END_STRUCT
END_TYPE

Биты будут упаковываться в байт. По мере заполнения места в байте и превышения его размера система увеличит размер структуры на еще один байт и так далее, экономя место. Аналогичная структура из полей типа BOOL будет занимать в восемь раз больше места, так как в памяти под одно поле типа BOOL отводится сразу целый байт.

Статьи в инфосисе: BIT и Structure → Bit access in structures.

Экономия не дается просто так. Для доступа к битовым полям требуется больше времени из-за операций упаковки-распаковки. Поэтому используйте их только для обмена данными с устройствами, а затем транслируйте в тип BOOL. Ниже результат, а код будет в конце поста. По вертикали время на исполнение цикла (меньше — быстрее):

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

Биты целочисленных данных

Целочисленные данные INT, BYTE, ... с самого начала позволяли читать и устанавливать свои отдельные биты. Достаточно написать iVar.3 и получить доступ к биту номер 3 (счет идет от нуля). Внезапно, нам подарили интересный механизм именования отдельных битов целочисленных данных. Проще говоря, теперь можно дать имена отдельным (или вообще всем) битам целого числа. Для этого лучше всего подходят константы, ведь в дальнейшем их значение нельзя будет изменить. Тем самым номер бита будет определен один единственный раз и не сможет изменяться в дальнейшем.

Можно создавать как локальные так и глобальные синонимы. С глобальными есть нюанс, поэтому испытания начнем с них. Идем в GVLs, создаем список GVL, название можно выбрать произвольное, пишем следующее:

//{attribute 'qualified_only'}
VAR_GLOBAL CONSTANT
    Enable:  INT   := 3;
    Disable: BYTE  := 5;
    Error:   DWORD := 15;
END_VAR

Важно (!) убрать атрибут 'qualified_only' и указать, что это константы. С включенным атрибутом работать не будет. Конкретный тип данных не важен, главное чтобы он был целочисленным. Значение константы (число) обозначает номер бита, нумерация по прежнему начинается с нуля.

Теперь ближе к коду, что именно можно с этим сделать?

PROGRAM MAIN
VAR
    iVar: LINT;
    bVar: BYTE;
END_VAR
VAR CONSTANT
    Enable:  WORD := 3;
    Ready:   WORD := 3;
    Disable: WORD := 5;
    Error:   WORD := 15;
END_VAR

iVar.Enable := TRUE;
IF iVar.Ready THEN
    iVar.Disable := FALSE;
END_IF

// bVar.Error := FALSE; >>> `Error` is no valid bit number for `bVar`

iVar.Enable установит бит разрешения #3, а iVar.Disable сбросит бит запрета #5. Выйти за разрядную сетку не получится, компилятор бдит еще на этапе сборки (см. комментарий про bVar).

Можно дать одному и тому же биту разные названия. В примере выше поля Enable и Ready — это имена-синонимы четвертого бита (бит №3). Иногда это удобно и наглядно:

iVar.Enable := TRUE;
// iVar = 2#0000_1000
// iVar.Ready == TRUE

iVar.Disable := TRUE;
// iVar = 2#0010_1000

iVar.Ready := FALSE;
// iVar = 2#0010_0000
// iVar.Enable = FALSE
  

Производительность

Любые операции с отдельными битами, независимо от типа операции, чтение ли это или установка бита, приведут к дополнительным операциям упаковки/распаковки битов в байты. Это конечно же отразиться на производительности. Да, это будут копейки относительно других операций (см. картинку выше), но давайте посмотрим как обстоят дела с операциями чтения и записи по отдельности, а в конце еще раз всё вместе:

Чтение требует чуть меньше времени, чем запись. Операции с отдельными битами требуют больше времени, чем работа с булевым типом. Комплексные операции чтение-запись привносят еще большую нагрузку. Но(!) еще раз повторюсь, здесь счет идет на десятки тысяч операций за один цикл. Не стоит выигрывать наносекунды за счет читаемости кода. Кстати, код:

Вебинар. TwinCAT 3 Eventlogger

И опять с просмотра вебинара начнем знакомство с Eventlogger'ом. То есть с чтения конспекта, пропущенного через инженера. Вебинар `TwinCAT 3 Eventlogger: event-based communications from the TwinCAT runtime system` прошел 8 мая 2018 года, но нас это не остановит, так как с возрастом продукт становится только стабильнее и, главное, понятнее. За счет выпущенной документации и конечно же опыта разработчика.

Изображение: Beckhoff Automation

Центральный компонент — EventLogger. Он встроен непосредственно в ядро TwinCAT и для своей работы не требует покупки или активации каких-либо лицензий. Это неотъемлемая часть ядра TwinCAT. Доступ к этому ядру ПЛК-программы осуществляют через библиотеки (например, Tc3_Eventlogger), а библиотеки в свою очередь через интерфейс COM-объектов TcСOM и ADS.

Изображение: Beckhoff Automation

Ряд сообщений можно автоматичеки пробрасывать в журналы Windows. Откройте "Просмотр событий" Windows (или EventLogger) и вы увидите ряд сообщений, таких же что и в TwinCAT. 

Eventlogger поддерживает произвольный набор сообщений, то есть вы можете создавать свои собственные сообщения и события. Вы можете конструировать их, встраивать в свои конфигурации, компилировать и затем использовать в своих системах. Для создания сообщений служит ветка Solution Explorer → SYSTEM → Type System в конфигурации проекта. Закладка справа Event Classes позволяет объединять сообщения в классы по каким-либо удобным для вас критериям. 

События представлены специальным типом данных TwinCAT. События управляются с помощью TwinCAT Type System. Следовательно они едины и одинаковы для всех компонентов проекта, написанных на любом из доступых язков программирования: ST, LD, C++, ... Плюс к этому, конфигурация событий хранится в TMC-файлах, соответственно это XML-файл, который можно легко автогенерировать с помощью произвольных (в том числе и внешних) инструментов.

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

Текст сообщений может параметризоваться. Можно добавить прямо в текст метки, которые в коде программы будут заменяться на актуальные значения: "Текущая температура {1} превышает {0}". Кроме этого, можно задать источник события и таким образом впоследствии увидеть, что сообщения одинакового типа отправляются из разных подпрограмм (источников).

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

Библиотека Tc3_EventLogger

Позволяет создавать события из программы ПЛК.

Сообщения (messages) просто создаются, а затем отправляются в системный лог. Это не реалтайм система: одно событие в миллисекунду. На самом можно отправлять больше одного за цикл, но это будет зависеть от производительности.

Кроме сообщений можно создавать "Тревоги" (Alarms) которые могут находиться в одном из состояний: тревога установлена (Raise), тревога сброшена (Release) и тревога квитирована (Confirm). Также можно полностью удалить экземпляр объекта тревоги из памяти (Clear), но в логе сообщения сообщение все равно остается и не пропадает. Иллюстрация из справочной системы:

Изображение: Beckhoff Automation

Работа из C++ очень похожа на работу из ST программ. Из C# тоже, но это будет отдельно.

Получение событий

Вы создаете новый класс, расширяя FB_ListenerBase. После этого создаете конфигурацию (.Subscribe) и добавляете в нее класс сообщений (.AddEventClass). Теперь необходимо вызывать каждый цикл объект (экземпляр созданного вами нового класса). В случае прихода сообщения, будут вызваны соответствующие методы класса.

Для C++ аналогично.

Доступ извне

События TwinCAT EventLogger можно просматривать в Visual Studio: View → Other Windows → TwinCAT Logged Events.

Программы написанные на C# могут получить дступ через ADS Proxy. С помощью класса TcEventLogger из сборки ADS. Причем текст сообщения можно получать с учетом интернационализации локали, то есть на разных языках в зависимости от предпочтений разработчика либо настроек системы.

Интернационализация

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

История K-Bus или INTERBUS

Несерьезные действия временами приводят к серьезным или по крайней мере полезным результатам. Как-то раз в проекте пропала конечная, защитная крышка EtherCAT шины. Чтобы как-то компенсировать стоимость крышки, да и скорее не стоимость, а время доставки, в голову коллеги явилась мысль заменить ее на терминал от K-Bus. Интуиция подсказала, что металлические контакты установлены не просто так, а несут какое-то назначение. В EtherCAT-крышке у нас только интеллектуальная пластмасса, а она, как известно, изолятор и ток не проводит. Модуль KL9010 был вскрыт, препарирован и свет увидели его потроха.

Внутри у него...

Модуль внутри пустой, но в зоне расопления(?) контактов, есть вставка из платы с контактными площадками и накладными-прижимными клеммами. Две из них попарно замкнуты перемычкой.

Kа-бас шина не будет работать, а точнее не будет обнаруживать дочерние устройства, если на ее конце не установить терминальный модуль KL9010. Теперь мы точно знаем, что там перемычка: два средних контакта из шести замкнуты перемычкой.

История

Я покопался в своем архиве и вытащил из-под груды ссылок занятный, но давно заброшенный блог Gadgets Inside с гикпроном внутренностей терминалов. Там есть бекхофф и там есть интересные заметки про шину K-bus.

Beckhoff KL4032, 2 channel, 12 bit, -10..+10V модуль выходов.

Beckhoff KL3062, 2 channel, 12 bit, 0..10V модуль входов.

KL is the “older” series of Beckhoff’s I/O modules, it incorporates the K-bus connection interface, which is basically an INTERBUS interface, but Beckhoff names it K-Bus (Koppler-Bus).

[...]

Beckhoff BK200A. Probably this is the INTERBUS protocol IC, but has a “Beckhoff brand”.

[...]

On the back side there is only one bigger (44 pins) IC named Beckhoff BK200A. This must be the INTERBUS protocol IC, just named in a “Beckhoff way”.

KL — это более старая [пост 2013 года] серия Бекхоффских модулей входов-выход. Модули построены вокруг К-bus интерфейса, который фактически является интерфейсом INTERBUS, но Бекхофф называет его K-Bus (Koppler-Bus).

Внутри модуля установлена микросхема Beckhoff BK200A. Вероятно, это обычный интерфейс протокола INTERBUS, но под брэндом Бекхофф.

С обратной стороны [это уже про другой терминал] платы находится только одна большая 44-пиновая микросхема, обозначенная как Beckhoff BK200A... дальше аналогично предыдущей выдержке.

Поверим паталогоанатому на слово и на выходные запишемся в межавтобусный клуб Interbus Club, а по дороге в клуб, полистаем брошюру INTERBUS Basics (interbus club).

Вступаем в клуб

Из брошюры узнаем, что:

This method is more efficient than the message-based method for a large number of devices. The summation frame method ensures fixed data lengths for devices and therefore constant transmission times. The determinism of this method is essential for the accurate calculation of the response time.

Этот метод более эффективен чем отправка отдельных сообщений большому количеству устройств. Использование метода объединения фреймов [в один большой] обеспечивает фиксированную длину данных от устройств и следовательно гарантирует постоянное [предсказуемое] время передачи [фрейма]. Предсказуемость данного метода — это основа точного подсчета времени отклика.

Знакомая философия, не так ли? Картинка для наглядности:

От 485-го к витым парам Ethernet. Протоколы мигрируют туда же. Полезно иногда оглянуться на историю.

Так что там с перемычкой?

Согласно описанию INTERBUS последний модуль должен замкнуть контакты номер 5 и 9, чтобы кольцо шины замкнулось. Что видимо и происходит в конечном модуле. Вот картинка из документации Бекхофф на коплер BK4000 (Interbus Bus Coupler):

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

Вебинар. EtherCAT терминалы энергоэффективности

Медлен спустимся и обозрим измерительные модули на основе вебинара EtherCAT Terminals for energy management. Ничего что с небольшим опозданием — вебинар все еще доступен в архиве, хотя и прошел в далеком 2018 году.

Изображение: Beckhoff Automation

Энергоэффективность

Энергоэффективность — это не только про доставку электричества, но и про:

• экономия энергии = экономия денежных средств.
• Доставка энергии = надежность и непрерывность производства.
• Производительность промышленности = повышение оборота.
• Управление ресурсами = повышение прибыли.

Чтобы этого достичь, нужно измерить энергию на различных этапах, которые в свою очередь представлены различными типами сред с различными технологическими параметрами: ток, теплоемкость/газ, вода, давление воздуха, температура, мониторинг отказов оборудования.

Изображение: Beckhoff Automation

Электроток

Модули объеденены в шесть групп по типу измеряемой среды (см. картинку выше). Затем модули объеденены в три функциональные группы:

• измерение (power measurement);
• мониторинг (power monitoring);
• эксплуатация (maintenance).

Эксплуатация

Это самые простые и дешевые терминалы: EL3423, EL3483. Они не производят измерения, а только сигнализируют о нормальном или ошибочном состоянии линии электропитания (трехфазной в том числе). Также модули выдают отчет о качестве питания, в виде собирательного параметра Power Quality Factor, скомпилированного из нескольких разных измерений.

Мониторинг

EL3443 — более расширенные возможности по сравнению с предыдущей моделью EL3403.

EL3453 — быстрее, чем EL3413 и лучше гальванически развязан (690В, до 60А в течении одной секунды).

Появились новые функции, опять-таки относительно EL3413 / EL3403:

• данные обновляются чаще, до 10мс (50Гц);
• обсчитывается больше гармоник (до 63);
• полностью конфигурируемые PDO;
• статистика измерения: мин-макс-среднее;
• детектирование выбросов тока и напряжения;
• измерение cos(𝜑) — коэффициент мощности (power factor);
• измерение угла фаз;
• сообщает об авариях: перекос фаз, утечки токов, и т. п.
• КЗ: около одной микросекунды для тока и напряжения.

Измерение

Все очень просто: EL37xx + TF3650. Основной акцент на новую (теперь в 2020 г. уже нет) библиотеку TF3650 | TC3 Power Monitoring.

Контроль и мониторинг питания

TF3650 | TC3 Power Monitoring — это ПЛК библиотека для обработки "сырых" данных, полученных от модуля, для одно- и трехфазных систем. Краткое содержание:

• ФБ для расчета RMS тока, напряжения и мощности.
• Вывод мгновенных или усредненных, минимальных и максимальных значений измеренных величин.
• Частоты, спектры, гармноники