Переменная через указатель, через 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`. В этом файле настраиваются соединения между целевым контроллером и ПК. Если контроллер  и ПК находятся на одной и той же машине, то настраивать этот файл не нужно. Можно просто удалить его.

Секретный сервис 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'); Продолжайте копать.

Производительность ReadAny и Reactive в 5.0.0-preview1

В продолжении темы измерения скорости чтения, посмотрим что там с превью версией под .NET Core 3. Заодно увидим как обстоят дела с реактивностью.

ReadAny

static void Main(string[] args)
{
    AdsSession session = new AdsSession(new AmsAddress("5.28.214.97.1.1", AmsPort.R0_RTS + 1));
    session.Connect();
    var connection = session.Connection;

    const int HOWMUCH = 1000;
    List results = new List();

    uint hMain_CycleCount = connection.CreateVariableHandle("MAIN.CycleCount");

    for (int i = 0; i < HOWMUCH; i++)
        results.Add(
            (uint)connection.ReadAny(hMain_CycleCount, typeof(uint)));

    foreach (var cycleNumber in results)
        Console.WriteLine(cycleNumber);
}

.NET Core 3, AdsRouterConsole

Для сравнения повтор картинки из предыдущего поста для .NET 4.7.1, TwinCAT.IO Router

Reactive

static void Main(string[] args)
{
    AdsSession session = new AdsSession(new AmsAddress("5.28.214.97.1.1", AmsPort.R0_RTS + 1));
    session.Connect();

    const int HOWMUCH = 1000;

    List<uint> results = new List<uint>();

    var valueObserver = Observer.Create(
        val => { // on next
            results.Add(val);
            //Console.WriteLine(val);
        },

        exc => { // on error
            Console.WriteLine(exc.Message);
        },

        () => {  //on completed
            Console.WriteLine($"Read {results.Count} cycles");

            foreach (var cycleNumber in results)
                Console.WriteLine(cycleNumber);
        });

    var subscription = session.Connection
        .WhenNotification("MAIN.CycleCount", NotificationSettings.ImmediatelyOnChange)
        .Take(HOWMUCH)
        .Subscribe(valueObserver);

    Console.WriteLine("ENTER to stop...");
    Console.ReadLine();
}

Все совсем плохо:

Отрицательные значения показывают, что пакеты прилетали не по порядку, а как-то иначе. Причем, если убрать условие в получении N-значений .Take(1000), и просто попытаться выбрать требуемое количество, то получится такая же точно каша с непоследовательными элементами. Что нарушает уверенность в целостности системы.

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

Пока что очень сыро и сильно напрягает непоследовательность приходящих элементов.

InvokeRpcMethod — вызов удаленного метода

С помощью ADS можно не только передавать данные, но и вызывать методы ПЛК задачи.

TcAdsClient client = new TcAdsClient();
client.Connect(new AmsAddress("5.28.214.97.1.1", AmsPort.R0_RTS + 1));

short result = -1;
var args = new object[]{ result, (short)1, (short)2 };
try {
    result = (short)client.InvokeRpcMethod("MAIN.fbBox", "M_FuncPub", args);
}
catch { }

PROGRAM / ACTION

Проверим странное...
...оно не работает. Нет такого символа

Value cannot be null.
Parameter name: symbol

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

FB

Action

Опять нестандартное. И оно тоже не работает.

The RPC method 'A_Func01' is not supported on symbol 'MAIN.fbBox!

Кстати, опечатка в сообщении эксепшена — не хватает кавычки.


Method

Для метода, ожидаемо, работает. Причем, внезапно, вызов метода работает даже когда Runtime в состоянии Stop. Иначе говоря, когда порт создан (851), но ПЛК задача еще не запущена.

Команда __NEW при RPC вызовах также работает, даже в состоянии "стоп", и по прежнему выжирает память роутера. Контроль памяти роутера описан в New, Delete и память роутера. Поэтому если память выделяется внутри RPC метода, а освобождается в другом месте — получится Ахтунг и протечка памяти!

Итоги:

• Уровень доступа метода не влияет на доступность извне. Любой из PUBLIC, PRIVATE, PROTECTED, INTERNAL доступен для внешнего вызова.
• Вызов требует наличия всех параметров объявленных в ФБ как VAR_INPUT
• Точки останова внутри методов не срабатывают при RPC вызовах.

Насколько быстро?

Тестировать будем на CX9020, x32, TwinCAT 3.1.4022.25 и на десктопе Core i7-3630QM x64 TwinCAT 3.1.4024.0. Для интереса сравним производительность относительно обычного чтения символа.

results[i] = (uint)client.InvokeRpcMethod("MAIN.fbBox", "M_FuncPub", args);
// VS
results[i] = (uint)client.ReadSymbol("MAIN.CycleCount", typeof(uint), false);

Будем последовательно и синхронно читать по 1000 значений за раз. В случае с InvokeRpcMethod соответственно вызывать метод и получать результат. Результатом же чтения будет номер текущего цикла ПЛК задачи. При последовательном и многократном чтении, получим массив номеров циклов. Сравнивая два соседних значения и умножая разницу на время цикла ПЛК задачи, получим время затраченное на чтение.

Начну с обычного чтения ReadSymbol. По горизонтали — номер выборки. По вертикали — время в миллисекундах, затраченное на чтение символа. Цветом обозначено время цикла ПЛК-задачи. Первым будет CX9020, вторая картинка — десктоп:

ReadSymbol, CX9020

ReadSymbol, десктоп Core i7 x64

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

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

Теперь про RPC запросы. Порядок контроллеров прежний:

RPC, CX9020

RPC, десктоп Core i7 x64

RPC выполняется дольше чем запрос данных одной переменной. Это ожидаемо, так как нужно принять запрос с аргументами, выполнить код, и только затем отправить ответ. 3-4-5 циклов, в зависимости от того, куда упадет запрос относительно границы кванта системного времени.

Правило 4мс по прежнему работает.

Выводы

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

Если же необходимо реализовать контурные режимы или передавать данные чаще чем раз в 4мс, то необходимо реализовать промежуточный буфер и отправлять несколько значений за раз, используя обычные функции для работы с переменными ReadAny, WriteSymbol, etc.

PS: Инструменты

Для проведения тестирования и рисования результатов, иногда достаточно обычного экселя (Excel), что и было использовано:

Вебинар. Новое поколении TwinCAT HMI

Много клиентов, много серверов, много рантаймов и много всего остального. Основной акцент на слово "много". Сводный обзор по возможностям и полезностям визуализаций в TwinCAT 3 провел Дэймон Томпсон (Daymon Thompson). По окончании на вопросы ответил глобальный продукт-манагер Свен Обершмидт (Sven Oberschmidt). По прежнему хочется "мяса" из инженеров.

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

Основные черты продукта:

• Основан на технологиях пришедших из интернета: html5, css3, javascript.
• Клиенты из-под браузеров (в том числе и Edge) и клиенты на мобильных системах Android и iOS, ведь там тоже есть браузеры, только мобильные.
• Система рассчитана на продолжительный срок жизни: придет и останется с нами надолго.
• Всё такое масштабируемое, модульное и независимое, векторное и веб-ориентированное. Если кратко и без патетики — должно стать удобнее как в разработке, так и в применении.

TwinCAT HMI Creator

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

• Интеграция с Visual Studio.
• Интеграция с TwinCAT.
• Редактор с упором на визуальную разработку.
• Использование систем контроля версий (tfs, svn, git, ...).
• Менеджер пакетов.
• Готовые шаблоны проектов.
• Темы оформления.
• Графическая библиотека готовых элементов: SVG, сложные и составные элементы.

TwinCAT HMI Framework

• Готовые контролы (элементы управления интерфейсом):
• стандартные;
• графики, чарты, события/логи/журналы (events);
• пользовательские (самодельные) контролы.
• Применение сложных типов данных (структуры, дата/время и пр.).
• Интернационализация:
• переключение языков;
• национальные единицы измерения, меры длины, денежные знаки и т. п.
• Расширябильность засчет html5 и javascritpt.

TwinCAT HMI Server

Веб-сервер написанный Бекхоффом (фирмой, а не человеком). Обещают, что будет работать на всем, что начинается с CX9020. В том числе и на Windows CE.

• ADS — что позволяет использовать рантайм как от TwinCAT 3, так и от TwinCAT 2.
• OPC UA — что позволит использовать вообще все что угодно.
• Цифровой осциллограф Scope. Пока не понятно куда и как он будет встраиваться, но возможно имеется в виду его серверная часть.
• Безопасность данных (https, tls и прочий эS).
• Уровни доступа пользователей (роли пользователей, login | logout).
• Предварительно подготовленные данные для тестирования и отладки (recipe management).
• Логирование событий.
• Сбор данных.
• Сможет расширяться модулями на C++ / C#.

Разработка

• Сплошная интеграция с Visual Studio.
• Живое взаимодействие с визуализацией во время разработки. Будет сразу видно, что и как работает.
• Графический редактор с набором стандартных и не очень элементов.
• Предварительно настроенные шаблоны, которые можно доработать. Обещают современный внешний вид с анимацией и прочими свистелками.
• Контролы пользователя расширяются с помощью javascript. Серверная часть расширяется на C++ / C#. Можно подготовить заранее темы в корпоративном стандарте под брендбук, а затем использовать во всех остальных проектах.

Про архитектуру уже было в Новый HMI для TwinCAT 3 (8 декабря 2015). Про сценарии применения было в Визуализации в TwinCAT 3 (24 марта 2016), но если кратко:

• Наиболее распространенный сценарий "локальный клиент": визуализация и браузер работают на одном контроллере, а графическая панель подключается через DVI.
• Много клиентов через интернет (например, мобильные телефоны и планшеты) подключаются к локальному клиенту.
• Много клиентов подключается к одной машине с сервером TwinCAT HMI, который собирает (агрегирует) данные с нескольких ADS-серверов (умных коплеров или младших моделей CX).
• Много TwinCAT HMI серверов, которые подключены к одной машине, которая отображает сводные данные со всех других серверов (сервер серверов).

При этом сохраняется мультипротокольность: сервер общается с коплерами по любым протоколам, клиенты подключаются к серверу через http(s) и браузеры.

Лицензирование

• Стоимость не зависит от количеств тегов. 
• Инструменты разработчика бесплатны, включая обновление, сопровождение и поддержку.
• Лицензирование касается только сервера. Клиенты работают бесплатно и не лицензируются.

Стоимость лицензии строится исходя из:

• уровня платформы на которой будет работать TwinCAT HMI Server;
• количества клиентов и целевых систем (target runtimes).

Пример

TF2000 HMI Server — рассчитан на 1 клиента (браузер) и  одну целевую систему (netId), то есть в базовой версии один клиент — один таргет.

Можно добавить клиентов или таргетов:
- TF20x0 Clients Pack 1/3/10/25 (пакет клиентов — один, три, десять дополнительных клиентов).
- TF20x0 Targets Pack 1/3/10/25 (пакет таргетов).

Можно добавить расширения визуализации HMI Extension (Scope, OPC UA) — это расширения для добавления протоколов или дополнительных функций.

В итоге будет сформирована лицензия TwinCAT 3 HMI License.

Итого

• Быстрая разработка, где мало разработки и больше рисования.
• HTML5, javascript.
• Клиент не зависит от платформы. 
• Модные веб-технологии.
• Гибкая архитектура.
• Модульность.

Вопросы-ответы

• Разница между TwinCAT PLC HMI и TwinCAT HMI? Первый будет только патчиться, новые фичи будут появляться только в TwinCAT HMI.
• Какие версии Visual Studio? Пока что 2013-2015. Дальше будет видно, а пока этого достаточно.
• Локальные переменные будут доступны (транслируются) в контекст браузера. Надо смотреть что там имелось в виду.
• Когда? В этом году (2016) немецкая версия, в начале следующего года для всех остальных, кто говорит на английском.
• Веб-сессии (sessions) поддерживаются, информация о веб-клиенте доступна.
• PLC HMI контролы и модные HMI контролы, да и другие элементы тоже, смешивать и перемещать туда-сюда нельзя. Вполне возможно, хотя и маловероятно, в будущем появится конвертер первого во второй, но не обратно.

Сервер Modbus TCP

Протокол Modbus поддерживается практически всеми производителями и реализован на многих устройствах. В TwinCAT он существует в виде модбас-сервера как для десктопа, так и для компактной Windows CE:

TS6250 | TwinCAT Modbus TCP Server
TS6250-0030 | TwinCAT Modbus TCP Server CE

В 8000 серии модбас-сервер уже встроен, но про 8000 серию мы разговаривать не будем, так как она мне не нравится.

Итак, чтобы установить — прочтите руководство по установке. Там все просто и подходит для всех видов операционок.

После установки получаем сервер и библиотеку с функциональными блоками. Библиотека позволяет использовать произвольные функции Modbus, работать в роли клиента или использовать UDP-протокол вместо скучного и надежного TCP.

Для передачи данных чаще используют заранее подготовленные глобальные переменные или области памяти, но если очень хочется, то порт и прочие настройки можно переназначить в файле настроек — TcModbusSrv.xml. Там же можно переназначить порты ADS и адреса смещений. В операционной системы CE | Compact файл должен лежать в \hard disk\system. Если его там нет — значит сервер настроен по умолчанию. Работа с файлом конфигурации описана в Mapping between Modbus and ADS.

Для настольных операционных систем существует готовый конфигуратор, после установки лежащий в x:\TwinCAT\TcModbusSrv.

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

Все начинается с <Configuration>. По умолчанию, как это принято в сетях Модбас, коммуникационный сетевой порт равен 502:

<!-- Modbus TCP port, default = 502-->
<Port>502</Port>

Далее идет раздел маппинга: <Mapping>, в котором задается отражение адресного пространства Modbus на адресное пространство операционного образа ПЛК или, проще говоря, к каким областям памяти контроллера приведут заданные адреса Modbus.

Начинаем конфигурировать дискретные входа (биты дискретных входов только для чтения): <InputCoils>. Если вы внезапно забыли о функциях Modbus — кратко ознакомьтесь с обзорной статьей: она короткая и надолго вас не задержит.

Задаем стартовый адрес пространства Modbus: <StartAddress>0</StartAddress>
...и конечный адрес: <EndAddress>32767</EndAddress>

Остается настроить место, куда эти адреса приведут на стороне контроллера. ADS-порт выбирает устройство на шине EtherCAT. 801 — это стандартный порт первого рантайма ПЛК-задачи:

<!-- AdsPort: TwinCAT2 PLC1 = 801, PLC2 = 811...-->
<AdsPort>801</AdsPort>

Затем идет индекс группы и смещения. Они конкретизируют переменные, области памяти и пр.:

<!-- IndexGroup 61473 = 0xF021 -> physical plc inputs %IX -->
<IndexGroup>61473</IndexGroup>

<!-- Bit offset-->
<IndexOffset>0</IndexOffset>

Большего быстродействия можно добиться, указывая индекс группы и смещения, как это сделано выше, но для удобства можно просто задать имя переменной:

<MappingInfo>
<AdsPort>801</AdsPort>

<!-- Modbus input coils -->
<StartAddress>32768</StartAddress>
<EndAddress>33023</EndAddress>

<VarName>.mb_Input_Coils</VarName>

</MappingInfo>
</InputCoils>

Обычно приводят простой пример в котором описывают мапинг переменных ПЛК-программы, но мы заглянем глубже — как сделать мапинг непосредственно ADS-шины. Для начала, необходимо включить ADS-сервер шины и задать номер порта (обычно 27907 для TwinCAT 2, но можно и другой):

TwinCAT 2: I/O - Configuration → I/O Devices → Device 1 (EtherCAT) → Device 1-Image → ADS → Enable ADS Server.
TwinCAT 3: I/O → Devices → Device 1 (EtherCAT) → Image → ADS → Enable ADS Server.

Номер функции Modbus как бы выбирает индекс группы (Index Group), тогда как адрес Modbus задает смещение области памяти, на которую отображаются переменные, а точнее часть операционного образа. Получается, что с помощью настроечного файла XML можно отразить не только образ данных ПЛК-задачи, но и любой другой образ. Например, образ области памяти данных EtherCAT-шины, что нам и требуется.

<MappingInfo>
<AdsPort>27907</AdsPort>

<!-- Modbus input coils -->
<StartAddress>32768</StartAddress>
<EndAddress>33023</EndAddress>

<VarName>Inputs.Frm0InputToggle</VarName>

Роутеры AMS и роутеры ADS

ADS (Automation Device Specification) – протокол взаимодействия устройств между собой, не зависит от оборудования и не зависит от шины по которой устройства общаются.

AMS (Automation Message Specification) – содержимое и структура сообщений ADS.

Каждое устройство или программный сервис ADS имеет свой уникальный номер или номер порта (AdsPortNr). Часть номеров заранее занята стандартными и системными сервисами.

Общение между ADS-устройствами может происходить поверх любой сети, а в разных сетях – разная адресация и, вообще, все разное. Кто-то должен перебрасывать мостик между «тем и другим»; в TwinCAT этим занимается AMS Message Router (AMS-роутер, ADS-роутер или просто роутер). Для примера, возьмем ситуацию, когда контроллер извне общается через Ethernet, а внутри через EtherCAT.

Каждый контроллер шины имеет собственный ADS-роутер. В данном случае, он будет транслировать IP-адреса и пакеты Ethernet в AmsNetId-адреса и пакеты EtherCAT. Например, на EtherCAT-шине AmsNetId-адрес устройства = 5.2.100.109.1.1, это же устройство на шине Ethernet может иметь адрес = 192.168.1.100.

Часто, для удобства, начальные части адресов делают одинаковыми: 192.168.1.100.1.1 и 192.168.1.100, но совпадать они не обязаны и часто совпадают из-за того, что конфигуратор автоматически сформировал AmsNetId-адрес из IP-адреса: взял IP-адрес и приписал к нему «.1.1».

ADS и AMS - это разные вещи: один – это архитектура устройств, другой – структура сообщений. Соответственно, ADS-роутер занимается передачей пакетов и трансляцией адресов между устройствами и сервисами. Термин AMS-роутер чаще употребляется в значении трансляции адресов.

• AMS-адреса никак не связаны с IPv6.
• AmsNetId – это на самом деле адрес AMS-роутера, а не устройства.
• Устройства (как и сервисы) адресуются по номеру порта: 801, 501, и т. п.

Настройка роутера

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

Диалог задает Static Route. Записи такого типа существуют вечно. Точнее, до тех пор, пока пользователь ее не удалит. Вечность записи обеспечивает системный реестр операционной системы:

HKEY_LOCAL_MACHINE\SOFTWARE\Beckhoff\TwinCAT\Remote\

Ключи можно удалять и добавлять через редактор реестра: роутер продолжит работать с новой конфигурацией, перезапускать его не требуется. Кстати, Slow Connection задает очень долгое ожидание подключения устройства и никак не влияет на скорость обмена с устройством. Если галку снять, таймаут будет равен двум секундам.

Если заглянуть под капот устройств c Windows CE 5/6/7, то мы увидим похожую картину. Разве что ветка реестра… хм, она будет той же самой.

В TwinCAT System Manager можно обнаружить еще несколько разновидностей роутинга: Temporary, Current и Project:

• Current – фикция и обман, всего лишь вкладка, отображающая на выбранном устройстве все активные на данный момент записи роутера.
• Project – запись роутера которая пропишется при активации конфигурации. Ее очень удобно хранить вместе с конфигурацией проекта (например, когда нужно «залить» 1500 контроллеров для «кинематического дождя»).
• Temporary – я долго искал, где она хранится, пока не обнаружил ее в памяти Windows-службы TwinCAT System Service. Соответственно, эти записи роутера живут до первого перезапуска сервиса или же перезапуска операционной системы (или контроллера).
• …и конечно же Static – его также можно создать здесь.

Если из системного лотка создаются записи для локальной системы, то с помощью System Manager можно создавать записи роутера для удаленной системы и записи между удаленными системами.

Стоит учесть, что не все устройства содержат полноценные роутеры – некоторые формируют AmsNetId на основе IP-адреса (например, так делали графические панели Вейнтек) или каким-либо другим способом. Тем не менее, перед работой с протоколом ADS нужно каким-либо способом создать записи в роутерах: как с «этой стороны», так и с «той стороны».