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

Из ПЛК задачи можно сделать 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 тока, напряжения и мощности.
• Вывод мгновенных или усредненных, минимальных и максимальных значений измеренных величин.
• Частоты, спектры, гармноники

Всё есть файл

В Unix/Linux устройства могут выступать в качестве файла или бинарного/символьного потока. Такая философия позволяет работать с потоком данных устройства, как с обычным файлом: открываем-читаем-пишем. Все что нужно — это иметь права доступа к устройству и знать протокол и структуру данных. В Windows иногда тоже можно. Попробуйте, например, создать на рабочем столе файл с именем com2.txt. Будет занято.

Источник

Сначала нужно определиться, что именно будем читать. Для начала я не стал брать последовательные порты или другие устройства, а решил воспользоваться псевдоустройством... поэтому будем читать случайные числа из /dev/urandom. Это не совсем то, что мне хотелось бы проверить, но пока обойдемся этим. Как вариант можно считать память операционной системы через /dev/mem. Сервис TwinCAT под BSD запускается с root доступом, поэтому проблем возникнуть не должно.

Прочитанное из устройства, можно просто сохранить в массив, но мы сделаем два дела сразу — кроме чтения устройства, сохраним результат в файл, лежащий на другом ПЛК. Итого: два ПЛК (один с TC/BSD, другой с Windows), соединены обычной локальной сетью Ethernet. На одном ПЛК читаем случайные числа из файла-псевдоустройства, а результат сохраняем на другой ПЛК в настоящий файл.

Код

Код настолько простой, что смотреть особенно не на что: ряд обычных файловых операций. Именно в этом заключается преимущество подхода "всё есть файл".

Открывать несколько файлов можно с помощью одного и того же ФБ. Главное делать это последовательно: сначала один, затем другой. Основная задача получить хендлер файла для дальнейших файловых операций. Нам нужно получить два хэндлера, от двух файлов, заданных следующими путями: sDevPath — задает путь к источнику '/dev/urandom' и sResPath — путь к файлу с результатом 'c:\dev\random.txt'. Сразу видно — где Юникс, а где Виндовс (подсказка, обратить внимание на /слэши/ в путях). В финале добавим в константы VAR CONSTANT адрес удаленного ПЛК: sRemoteNetId = '172.17.176.49.1.1'.

Будем читать бинарные данные, то есть числа в виде потока байтов. Поэтому при открытии файла необходимо установить флаг бинарного режима чтения nMode := ... FOPEN_MODEBINARY. Кстати, читать можно и блоками по несколько килобайт за раз, но в данном случае так проще сохранять числа в виде текста.

В остальном все очень просто: открываем, читаем, обрабатываем-конвертируем и сохраняем. Преобразование значения байта как числа из диапазона 0..255 в текстовый вид делается в строке:

tmpStr := CONCAT(BYTE_TO_STRING(buf), '$r$n');

... а в конце добавляем символ '$r$n' — перевод каретки CRLF, таким образом выстраивая числа в столбик. Позднее, я засуну эти случайные числа в Эксель для анализа.

Набрав достаточное количество чисел, стоит вежливо остановить процесс через принудительную установку переменной RUN в значение FALSE. Резкая остановка работы программы, чревато тем, что на приемной стороне файл с результатом останется открытым и занятым: ни прочитать, ни удалить. Если такое произойдет, необходимо на приемной стороне вручную перезапустить системный сервис TwinCAT System Service или выполнить из командной строки с привелегиями администратора: powershell -command "Restart-Service TcSysSrv -Force". Заметьте, какой уровень доверия возникает на двух ПЛК, между которыми налажен роутинг. Это к вопросу о безопасности и отказоустойчивости по обе стороны сетевого кабеля.

Анализируем случайные числа

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

Интересно посмотреть как распределяется нагрузка по ядрам. Всего виртуальной машине выделены два ядра, но не факт, что ядра настоящие: возможно, что и просто два потока (хост с гипертредингом). Зато видно как нагружен TcSystemService — системный сервис TwinCAT:

Вместо диспетчера задач здесь используется утилита top или можно установить более красивый htop: doas pkg install htop. На картинке выше используется htop.