Table of Contents

3.4.5 Описание модели ModbusDeviceList.xlsx — настройка опроса устройств по Modbus TCP/IP

Файл ModbusDeviceList.xlsx является моделью верхнего уровня и служит входными данными для встроенного модуля системы AutomiqAutomation — «ModbusDevices – Генератор устройств Modbus».

Его основное назначение — автоматическая генерация и настройка объектов в проекте alpha.DevStudio для опроса внешних устройств по протоколу Modbus TCP/IP, например контроллеры EKF PRO-Logic.

🔗 Расположение: JSC\USR\PRJ\Conf\DevStudioDevs\Modbus\ModbusDeviceList.xlsx

3.4.5.1 Назначение и функциональность

Модуль «ModbusDevices – Генератор устройств Modbus» предназначен для полной автоматизации процесса создания и настройки объектов в проекте DevStudio. Он может как создавать новые, так и модифицировать существующие устройства, структуры, настройки и свойства.

Генерируемые объекты:

  • Физические устройства (Slave): Создаются в полевом домене проекта DevStudio.
  • Драйверы Modbus Slave: Настраиваются внутри каждого физического устройства.
  • ПЛК-представления (PLC View): Создаются в Application для отображения данных с устройств.
  • Объекты диагностики связи: Автоматически генерируются сигналы диагностики (Ping, Invalid, Fault) для мониторинга состояния связи.
  • IOS-представления: Создаются на сервере для сервисного узла, что позволяет отображать состояние устройства на мнемосхемах HMI.
  • Привязка к Modbus-мастеру: В сервере DevStudio (ModbusTcpMaster) автоматически добавляется ссылка на созданное Slave-устройство.

Дополнительные функции:

  • Настройка сетевых адаптеров (IP-адресов) для устройств.
  • Поддержка очистки объекта перед генерацией (опция в настройках модуля).

3.4.5.2 Структура и содержание файла ModbusDeviceList.xlsx

Файл содержит один или несколько листов, начинающихся с префикса OBJ. (например, OBJ.Devices). Каждая строка на листе описывает один уникальный экземпляр физического Modbus-устройства.

Ключевые столбцы:

Столбец Описание
IsDevice Флаг, всегда устанавливается в +. Указывает генератору, что данная строка описывает устройство.
Domain Глобальная позиция (подстанция), к которой принадлежит устройство.
TAG Уникальный тег устройства. Используется для формирования имен и путей.
PathDevStudio Путь к объекту в дереве проекта DevStudio (например, root.P0_80_010.Devices).
HmiTag Путь к мнемокадру (HMI), на котором будет отображаться объект.
OBJTYPENAME Ключевой столбец. Имя модели устройства (OBJTYPE), которая определяет его поведение и диагностику (например, TreiS304, MbTcpDevice).
iTCPAddr_1, iTCPAddr_2, iTCPAddr_3, iTCPAddr_4 Четыре октета IP-адреса устройства.
Port Номер порта Modbus TCP/IP (обычно 502).
%JSC%\Usr\Prj\Conf\Models\DsModbusDevices\$S.xlsx Ключевой столбец. Ссылка на файл с описанием экземпляров объектов, находящихся внутри данного физического Modbus-устройства. Переменная $S подменяется на имя файла (например, P0-80-010-JF01-CN1001-1A1.xlsx).

Примечание: Ниже приведен пример заполнения листа OBJ.Devices в файле ModbusDeviceList.xlsx.

Рисунок 3.4.5.1 – Пример заполнения листа OBJ.Devices

[Вставьте изображение: Скриншот листа OBJ.Devices из ModbusDeviceList.xlsx, показывающий строки с IsDevice=+, IP-адресами и ссылками на файлы экземпляров.]

3.4.5.3 Модель устройства (OBJTYPE) и файл с описанием экземпляров

1. Модель устройства (OBJTYPE):

  • Расположение: JSC\Conf\Models\ObjTypes\Diagnostic\Modbus\.
  • Назначение: Определяет типовое поведение и диагностику физического устройства (например, TreiS304.xls для коммутаторов, MbTcpDevice.xls для устройств с одним адаптером).
  • Ключевой лист: NetDiag.opt
    • Содержит пути к базовым типам представлений в библиотеке (DevStudioDeviceNamePath, DevStudioIosTypePath, DevStudioServicePathAdapter_1, DevStudioServicePathAdapter_2).
    • Определяет имя менеджера (ManagerName).
    • Отличается количеством параметров в зависимости от числа сетевых адаптеров (один или два).

Примечание: Ниже приведен пример листа NetDiag.opt для модели MbTcpDevice.xls.

Рисунок 3.4.5.2 – Лист NetDiag.opt модели MbTcpDevice.xls

[Вставьте изображение: Скриншот листа NetDiag.opt из MbTcpDevice.xls, показывающий параметры ManagerName, DevStudioDeviceNamePath и т.д.]

2. Файл с описанием экземпляров объектов (P0-80-010-JF01-CN1001-1A1.xlsx и др.):

  • Расположение: JSC\USR\PRJ\Conf\Models\DsModbusDevices\EKF\.
  • Назначение: Содержит описание всех дискретных входов, выходов и других параметров контроллера EKF PRO-Logic, которые находятся внутри одного физического Modbus-устройства, объявленного в ModbusDeviceList.xlsx. Также содержит карту адресов Modbus (MBM.map).
  • Структура:
    • Лист OBJ.TechObject: Описывает экземпляры дискретных входов/выходов.
    • Лист MBM.map: Определяет привязку регистров Modbus к тегам объектов.
  • Особенность обработки: Строки на листах OBJ.* в этом файле обрабатываются инструкцией IOBJ. Это указывает конфигуратору, что все описанные в них объекты являются "дочерними" по отношению к родительскому Modbus-устройству, созданному на основе строки в ModbusDeviceList.xlsx, где была использована инструкция IOBJ.

Пример для контроллера EKF PRO-Logic:

  • В ModbusDeviceList.xlsx добавляется строка для контроллера с TAG=P0-80-010-JF01-CN1001-1A1, OBJTYPENAME=MbTcpDevice и ссылкой на P0-80-010-JF01-CN1001-1A1.xlsx.
  • В файле P0-80-010-JF01-CN1001-1A1.xlsx на листе OBJ.TechObject описываются все дискретные входы (DI) и выходы (DO) контроллера.
  • На листе MBM.map формируется карта привязки каналов к адресам Modbus в соответствии с документом "F100 10 вв PRO-Logic EKF PROxima F100-10-R (Modbus map).pdf":
    • Дискретные входы (DI) привязываются к регистрам с адреса 00001.
    • Дискретные выходы (COIL) привязываются к регистрам с адреса 00011.

Примечание: Ниже приведен пример структуры каталога DsModbusDevices.

Рисунок 3.4.5.3 – Структура каталога JSC\USR\PRJ\Conf\Models\DsModbusDevices

[Вставьте изображение: Скриншот проводника, показывающий каталог DsModbusDevices и подкаталог EKF с файлом P0-80-010-JF01-CN1001-1A1.xlsx.]

3.4.5.4 Описание файла модели с экземплярами

Файл, на который ссылается столбец %JSC%\Usr\Prj\Conf\Models\DsModbusDevices\$S.xlsx, является ключевым для определения состава и структуры данных, опрашиваемых с физического Modbus-устройства. Этот файл содержит три основных компонента:

1. Лист OPT.Device (Опции устройства):

  • Назначение: Содержит глобальные настройки для данного конкретного экземпляра устройства.
  • Содержание: Включает параметры, такие как имя шлюза (modbus.gate), порт, а также пути к внешним файлам с картами регистров и фреймами. По умолчанию настройки являются общими для всех устройств одного типа, но могут быть изменены для конкретного экземпляра.

2. Листы OBJ.* (Описание экземпляров объектов):

  • Назначение: Содержат список всех технических объектов (датчиков, исполнительных механизмов, дискретных входов/выходов), которые находятся внутри данного Modbus-устройства.
  • Структура: Аналогична листам OBJ.* в модели ПЛК. Каждая строка описывает один объект с его TAG, parentDescr, EqtDescr, OBJTYPENAME и другими атрибутами.
  • Особенность: Эти объекты не являются физическими устройствами, а представляют собой логические точки данных, которые будут опрашиваться через родительское Modbus-устройство.

3. Лист MBM.map (Карта Modbus):

  • Назначение: Определяет привязку каналов технических объектов (с листов OBJ.*) к конкретным адресам регистров Modbus.
  • Ключевые столбцы:
    • techObj: Тег технического объекта из листа OBJ.*.
    • channel: Канал объекта, который нужно опросить (например, Value, Status).
    • MemoryArea: Тип регистра Modbus (Input Register, Holding Register, Discrete Input, Discrete COIL).
    • Address: Адрес регистра.
  • Важно: Разработчик сам вручную определяет, какой канал какого объекта будет привязан к какому адресу Modbus, используя техническую документацию на устройство. Конфигуратор не может автоматически установить эту привязку.

Примечание: Ниже приведен пример заполнения листа MBM.map для контроллера EKF PRO-Logic.

Рисунок 3.4.5.4 – Пример заполнения листа MBM.map

[Вставьте изображение: Скриншот листа MBM.map из P0-80-010-JF01-CN1001-1A1.xlsx, показывающий привязку тегов к адресам регистров.]

3.4.5.5 Алгоритм обработки устройства Modbus TCP

Обработка каждого устройства в ModbusDeviceList.xlsx происходит по следующему алгоритму:

  1. Инициализация: Модуль обнаруживает строку с IsDevice=+ и извлекает из нее базовые параметры: TAG, Domain, IP-адрес, Port, OBJTYPENAME и путь к файлу экземпляров ($S.xlsx).

    Требуется изображение: Скриншот строки в ModbusDeviceList.xlsx с выделенными извлекаемыми параметрами.

  2. Загрузка модели устройства (OBJTYPE): Модуль загружает файл модели по имени из OBJTYPENAME (например, MbTcpDevice.xls) и считывает параметры с листа NetDiag.opt. Это определяет тип устройства, его диагностику и количество сетевых адаптеров.

    Требуется изображение: Скриншот дерева проекта конфигуратора, показывающего процесс загрузки модели MbTcpDevice.xls.

  3. Загрузка файла экземпляров: Модуль загружает файл, указанный в столбце %JSC%\Usr\Prj\Conf\Models\DsModbusDevices\$S.xlsx, и обрабатывает его листы OBJ.* с помощью инструкции IOBJ. Это создает "дочерние" объекты (датчики, исполнительные механизмы), которые будут опрашиваться через данное Modbus-устройство.

    Требуется изображение: Скриншот процесса обработки листа OBJ.TechObject с помощью инструкции IOBJ.

  4. Формирование карты Modbus: Модуль считывает лист MBM.map из файла экземпляров, который содержит привязку тегов дочерних объектов к конкретным адресам регистров Modbus (Input Register, Holding Register и т.д.).

    Требуется изображение: Скриншот процесса чтения и сопоставления данных с листа MBM.map.

  5. Создание объектов в DevStudio: На основе собранной информации модуль создает:

    • Физическое устройство в полевом домене с настроенным IP-адресом.
    • Драйвер Modbus Slave внутри устройства.
    • ПЛК-представление в Application, содержащее все дочерние объекты.
    • Объекты диагностики (Ping, Invalid, Fault) для мониторинга состояния связи.
    • IOS-представление на сервере для отображения на мнемосхемах.

    Требуется изображение: Скриншот интерфейса DevStudio, показывающий процесс создания физического устройства и драйвера.

  6. Привязка к мастеру: В существующем менеджере ModbusTcpMaster на сервере DevStudio создается ссылка на только что сформированное Slave-устройство.

    Требуется изображение: Скриншот менеджера ModbusTcpMaster в DevStudio с добавленной ссылкой на новое Slave-устройство.

  7. Завершение: Процесс повторяется для всех строк в файле. После обработки всех устройств генерация считается завершенной.

    Требуется изображение: Скриншот окна модуля ModbusDevices с отметкой о завершении генерации.