Difference between revisions of "Modules/ModBus/uk"

Revision as of 14:16, 28 January 2024

ModBus — комунікаційний протокол, заснований на клієнт-серверній архітектурі. Розроблений фірмою Modicon для використання у контролерах з програмованою логікою (ПЛК). Став стандартом де-факто у промисловості та широко застосовується для організації зв'язку промислового електронного обладнання. Використовується для передачі даних через послідовні лінії зв'язку RS-485, RS-422, RS-232, а також мережі TCP/IP. На цей час підтримується некомерційною організацією ModBus-IDA.

Існує три режими протоколу: ModBus/RTU, ModBus/ASCII та ModBus/TCP. Перші два використовують послідовні лінії зв'язку (переважно RS-485, рідше RS-422/RS-232), останній використовує мережі TCP/IP для передачі даних.

Модуль збору даних надає можливість збирати інформацію з різних джерел за протоколом ModBus у всіх режимах. Також, модулем реалізуються функції горизонтального резервування, а саме — спільної роботи з віддаленою станцією цього-ж рівня. В той же час, модуль протоколу дозволяє сформувати та видати дані за протоколом ModBus у різних режимах та через інтерфейси, які підтримуються модулями підсистеми "Транспорти".

1 Загальний опис протоколу ModBus

Протокол ModBus/{RTU,ASCII} припускає один ведучий (запити) пристрій у лінії (master), який може передавати команди одному або декільком веденим пристроям (slave), звертаючись до них за унікальною адресою у лінії. Синтаксис команд протоколу дозволяє адресувати 247 пристроїв на одній лінії зв'язку стандарту RS-485 (рідше RS-422 або RS-232). У випадку з режимом TCP, адресація виключена з протоколу, оскільки здійснюється на рівні TCP/IP стека.

Ініціатива здійснення обміну завжди виходить від ведучого пристрою. Ведені пристрої прослуховують лінію зв'язку. Майстер подає запит (посилка, послідовність байт) у лінію та переходить у режим прослуховування лінії зв'язку. Ведений пристрій відповідає на запит, який надійшов на його адресу.

Закінчення посилки відповіді визначається залежно від режиму. У режимі RTU закінчення посилки визначається за інтервалом часу між закінченням прийому попереднього байту та початком прийому наступного — час символу. Якщо цей інтервал перевищив час, потрібний для прийому півтори байти на визначеній швидкості передачі то прийом фрейму відповіді вважається завершеним. У режимі ASCII критерієм закінчення посилки є символ '\r', а у режимі TCP — очікуваний розмір посилки, інформація про який присутня у заголовку пакету.

1.1 Адресація

Всі операції з даними прив'язано до нуля, кожний вид даних (регістр, біт, регістр входу або біт входу) починається з адреси 0 та закінчується 65535.

1.2 Стандартні коди функцій

У протоколі ModBus можна виокремити декілька множин команд (Таблиця 1).

Таблиця 1: Підмножини команд протоколу ModBus

Модулем збору даних використовуються команди 3 та 6(16) для читання та запису регістрів, 1 та 5(15) для читання та запису бітів, 2 та 4 для читання біту та регістру входу, відповідно. Для реалізації інших та нетипових команд модулем передбачено функцію API користувацького програмування, яку можна викликати з процедури шаблону логічного рівня, надсилаючи довільні PDU-пакети та обробляючи отримані у відповідь.

Модуль протоколу обслуговує запити командами 3 та 6(16) для читання та запису регістрів, 1 та 5(15) для читання та запису бітів.

2 Модуль реалізації протоколу

Модуль протоколу ModBus містить код реалізації протокольної частини ModBus, а саме — особливості варіантів протоколів ModBus/TCP, ModBus/RTU та ModBus/ASCII. Модуль протоколу, спільно з обраним транспортом, активно використовується модулем збору даних для здійснення безпосередніх запитів. Оскільки модуль протоколу є автономним то, використовуючи його, можна створювати додаткові модулі збору даних за посередництвом нестандартних функцій розширення ModBus різного обладнання автоматизації.

2.1 API функції вихідних запитів

API функції вихідних запитів (messIO()) оперують обміном блоками PDU, загорнутими у XML-пакети, з відповідною структурою:

• <{prt} id="{sId}" reqTm="{reqTm}" node="{node}" reqTry="{reqTry}">{pdu}</{prt}>

Де:

• prt — ім'я тегу запиту з назвою використаного варіанту протоколу (TCP, RTU або ASCII).
• sId — ідентифікатор джерела запиту. Використовується для розташування до звіту вихідного протоколу.
• reqTm — час запиту, а саме — час, протягом якого, очікувати відповіді, у мілісекундах.
• node — номер вузла призначення або ідентифікатор юніту ModBus/TCP.
• reqTry — кількість спроб повтору запиту з помилкою у відповіді. Тільки для варіантів ModBus/{RTU,ASCII}.
• pdu — безпосередньо блок юніту даних (PDU) протоколу ModBus.

Результатний pdu у XML-пакеті замінює pdu запиту, а також встановлюється атрибут "err" з кодом та текстом помилки, якщо така мала місце.

2.2 Обслуговування запитів за протоколом ModBus

Вхідна частина, обслуговування запитів до модуля протоколу, здійснює перевірку та обробку запитів за посередництвом передбачених модулем об'єктів вузлів (рис.1). Фактично, реалізується механізм, який дозволяє OpenSCADA виконувати роль серверу ModBus/TCP або підлеглого пристрою ModBus/{RTU,ASCII}. Таким чином, OpenSCADA отримує можливість використовуватися у ролі будь якого учасника мережі ModBus.

Рис.1. Вкладка переліку вузлів обслуговування вхідних запитів протоколу.

Вузол протоколу еквівалентно фізичному вузлу пристрою мережі ModBus та може працювати у трьох режимах:

• "Дані" — режим відображення даних OpenSCADA на масиви регістрів та бітів ModBus з передачею їх за запитом клієнтського вузла або майстра.
• "Шлюз вузла" — режим переспрямування (шлюзування) запитів до вузла у іншій мережі ModBus через цей вузол.
• "Шлюз мережі" — режим переспрямування запитів до будь якого вузла у іншу мережі ModBus, фактично виконуючи інтеграцію декількох мереж ModBus у одну.

Оскільки вузлів протоколу може бути створено багато то виходить, що на одному інтерфейсі, тобто у одній мережі, одна станція на основі OpenSCADA може прозоро представляти декілька вузлів мережі ModBus з різними даними.

Розглянемо особливості конфігурації вузла протоколу у різних режимах.

2.2.1 Режим "Дані"

Режим використовується для відображення даних OpenSCADA на масиви регістрів та бітів ModBus. Загальна конфігурація вузла здійснюється у вкладці "Вузол" (рис.2) параметрами:

• Стан вузла, а саме: статус, "Ввімкнено" та ім'я БД, яка містить конфігурацію, з відстеженням наявності даних у різних сховищах та наданням послідовного видалення дублікатів.
• Ідентифікатор, ім'я та опис вузла.
• Стан "Ввімкнено", у який переводити вузол при завантажені.
• Адреса вузла мережі ModBus від 1 до 247.
• Вхідний транспорт, до мережі якого належить вузол. Обирається із переліку вхідних транспортів підсистеми "Транспорти" OpenSCADA. Вказання символу "*" у якості транспорту робить цей вузол учасником будь якої мережі ModBus з обробкою запитів від будь якого транспорту.
• Варіант протоколу ModBus, запити у якому має обробляти вузол, із переліку: Всі, RTU, ASCII, TCP/IP.
• Вибір режиму, у даному випадку це режим "Дані".
• Період обчислення даних у секундах. Вказує період обробки даних, які формуються для запитів, а саме: таблиці даних ModBus, програми обчислення даних та обслуговування посилання на дані OpenSCADA.
• DAQ шаблон або мова прямої процедури. Передбачає обрання шаблону або мови прямої процедури для формування та обчислення таблиць даних ModBus, а також для обслуговування зовнішніх посилань на модель даних підсистеми "Збір Даних".

Вузлом у цьому режимі обробляються наступні стандартні команди протоколу ModBus:

• 1 — читання групи бітів;
• 2 — читання групи бітів входів;
• 3 — читання групи регістрів;
• 4 — читання групи регістрів входів;
• 5 — встановлення одного біту;
• 6 — встановлення одного регістру;
• 15 — встановлення групи бітів;
• 16 — встановлення групи регістрів.

Рис.2. Вкладка "Вузол" сторінки конфігурації вузла протоколу у режимі "Дані".

Для формування таблиці віддзеркалення даних мережі ModBus, а саме регістрів та бітів, передбачається вкладка "Дані" (рис.3). Вкладка "Дані" містить таблицю параметрів та програму обробки параметрів визначеною мовою програмування доступною у OpenSCADA, але за шаблоном тут доступно тільки таблицю та у режимі "Ввімкнено". Таблиця містить параметри з властивостями:

• Ідентифікатор — ідентифікатор параметра, є ключовим у формуванні таблиць регістрів та бітів ModBus. Регістри та біти ModBus визначаються наступним чином:

• R{N}[w~], RI{N}[w~] — специфічна форма регістру та регістру входу, може бути розширено суфіксами: "i"—Int32, "f"—Float, "d"—Double, "s"—Рядок (розмір по замовченню 10 та до 100 регістрів);
• R:{N}[:w~], RI:{N}[:w~] — класична форма регістру та регістру входу, може бути розширено суфіксами: "i4"—Int32, "i8"—Int64, "f"—Float, "d"—Double, "s"—Рядок;
• C{N}[w], CI{N}[w], C:{N}[:w], CI:{N}[:w] — біт та біт входу.

Де:

• {N} — адреса даних ModBus пристрою (десяткова, шістнадцяткова, або вісімкова) [0...65535];
• w~e — прапорці: режим запису 'w', інверсія порядку регістрів '~', перемикання порядку байтів 'e' регістрів (у LE загалом та BE для рядків).

Приклади:

"R0x300" — доступ до регістру;

"C100w" — доступ до біту, доступний для запису;

"R_f200", "R_f200~" — отримати реальне з регістрів 200 та 201, 201 та 200;

"R_i400,300" — отримати int32 з регістрів 400 та 300;

"R_s15,20" — отримати рядок, блок регістрів, з регістру 15 та розміром 20;

"R_i8:0x10:w" — отримати та встановити int64 у регістри [0x10-0x13];

"R_d:0x20,0x30" — отримати реальне подвійної точності (8 байтів) з регістрів [0x20,0x30-0x32].

Всі інші параметри, які не потрапили під вище-зазначені правила, є внутрішніми, використовуються для різних проміжних обчислень, обробки, перетворень та значення їх може бути оперативно проконтрольовано та змінено з цієї таблиці у режимі виконання.

• Ім'я — ім'я параметру, використовується для іменування зв'язку.
• Тип — тип параметру із переліку: "Реальний", "Цілий", "Логічний" та "Рядок". Для регістрів та бітів ModBus має сенс встановлювати "Цілий" та "Логічний" тип відповідно. Для регістрів, розширених пріфіксами "f" та "s", треба вказати типи "Реальний" та "Рядок", відповідно.
• Зв'язок — ознака того, що цей параметр має пов'язуватися з атрибутом параметру підсистеми "Збір даних". Вказані цією ознакою зв'язки встановлюються у вкладці "Конфігурація шаблону".
• Значення — початкове або поточне значення параметру, якщо вузол включено.

В таблиці, по замовченню, визначаються декілька параметрів спеціального призначення:

• f_frq — частота обчислення таблиці програмою;
• f_start — ознака першого виконання — запуску програми.
• f_stop — ознака останнього виконання — зупинки програми.

Оскільки у вказівнику розширених типів регістрів може використовуватися недозволений символ ',' то доступ до нього із програми можна здійснити тільки альтернативним способом, через об'єкт "arguments":

arguments["R_s10,5w"] = "9876543210";

Рис.3. Вкладка "Дані" сторінки конфігурації вузла протоколу у режимі "Дані".

Для параметрів вказаних у якості зв'язків, зв'язки можна встановити для ввімкненого вузла протоколу та у вкладці "Конфігурація шаблону" (рис.4).

Рис.4. Вкладка "Конфігурація шаблону" сторінки конфігурації вузла протоколу у режимі "Дані".

2.2.2 Режим "Шлюз вузла"

Режим використовується для переспрямування запиту до окремого пристрою у іншій мережі ModBus, із мережі ModBus для якої сконфігуровано цей вузол. Загальна конфігурація вузла здійснюється у вкладці "Вузол" (рис.5) параметрами:

• Стан вузла, а саме: статус, "Ввімкнено" та ім'я БД, яка містить конфігурацію.
• Ідентифікатор, ім'я та опис вузла.
• Стан "Ввімкнено", у який переводити вузол при завантажені.
• Адрес вузла вхідної мережі ModBus, від 1 до 247.
• Вхідний транспорт, до мережі якого має стосунок вузол. Обирається з переліку вхідних транспортів підсистеми "Транспорти" OpenSCADA. Вказання символу "*" у якості транспорту робить цей вузол учасником будь якої мережі ModBus з обробкою запитів від будь якого транспорту.
• Варіант протоколу ModBus, запити у якому має оброблятися вузлом, з переліку: Всі, RTU, ASCII, TCP/IP.
• Вибір режиму, в цьому випадку цей режим "Шлюз вузла".
• Транспорт, у який переспрямовують запит, з переліку вихідних транспортів підсистеми "Транспорти".
• Протокол, у якому переспрямовувати запит.
• Адреса вузла мережі ModBus, від 1 до 247, у яку переспрямовується запит.

Рис.5. Вкладка "Вузол" сторінки конфігурації вузла протоколу у режимі "Шлюз вузла".

2.2.3 Режим "Шлюз мережі"

Режим використовується для переспрямування запитів мережі цілком у іншу мережу ModBus, з мережі ModBus для якої сконфігуровано цей вузол протоколу. Тобто, запит на пристрій з будь якою адресою буде спрямовуватися у іншу мережу, без переадресування. Загальна конфігурація вузла протоколу здійснюється у вкладці "Вузол" (рис.6) параметрами:

• Стан вузла, а саме: статус, "Ввімкнено" та ім'я БД, яка містить конфігурацію.
• Ідентифікатор, ім'я та опис вузла.
• Стан "Ввімкнено", у який переводити вузол при завантажені.
• Вхідний транспорт мережі, з якого переспрямовуються запити. Обирається з переліку вхідних транспортів підсистеми "Транспорти" OpenSCADA.
• Варіант протоколу ModBus, запити у якому має обробляти вузол, із переліку: Всі, RTU, ASCII, TCP/IP.
• Вибір режиму, у цьому випадку цей режим "Шлюз мережі".
• Транспорт мережі, у яку переспрямовувати запит, з переліку вихідних транспортів підсистеми "Транспорти".
• Протокол, у якому переспрямовувати запит.

Рис.6. Вкладка "Вузол" сторінки конфігурації вузла протоколу у режимі "Шлюз мережі".

2.3 Звіт запитів ModBus

Для контролю та діагностики за коректністю здійснення запитів різними компонентами, модулем надається можливість включення звіту запитів, що проходять через модуль протоколу. Звіт включається вказанням ненульової кількості записів у вкладці "Звіт" сторінки модуля протоколу (рис.7).

Цей механізм переважно є застарілим, оскільки його функції наразі виконуються ядром програми:

• діагностика джерела даних;
• протокол трафіку через транспорт.

Рис.7. Вкладка "Звіт" сторінки модуля протоколу.

3 Модуль збору даних

Модуль збору даних надає можливість опитування та запису регістрів та бітів пристроїв за посередництвом режимів протоколу TCP, RTU, ASCII та команд запиту 1 — 6, 15, 16.

3.1 Об'єкт контролеру

Для додання джерела даних ModBus створюється та конфігурується об'єкт контролеру OpenSCADA. Приклад вкладки конфігурації объекту контролеру даного типу наведено на рисунку 8.

Рис.8. Вкладка конфігурації об'єкту контролеру.

Using this tab you can set:

• The state of the controller object, as follows: Status, "Enabled", "Running" and the name of the database containing the configuration.

Manual restart of the enabled controller object causes the force reformation of the acquisition blocks.

• Identifier, name and description of the controller.
• The state "Enabled" and "Running", in which the controller object must be translated at boot.
• Policy of scheduling and priority of the data acquisition task.
• ModBus protocol, used for requesting the real device (TCP/IP, RTU or ASCII).
• Address of the output transport using the unified connection with navigation. Default port of the ModuBus/TCP is 502. The field may be set to empty and be changed at the runtime. Format of the address is:
  • "{TrModule}.[out_]{TrID}[:{TrAddr}]" — typical output with automatic creation TrID at it missing and providing TrAddr;
  • "{TrModule}.in_{TrID}:{RemConId}" — initiative input with the connection identifier in RemConId.
• ModBus destination node. In the case of protocols RTU and ASCII this is the unique address of the physical device, and when TCP/IP this is the identifier of the unity.
• Merging of the data fragments. Standard functions 1-4 let to request at once multiple adjacent registers or bits. This strategy often allows to optimize the traffic and time. However, the required registers are not always located adjacent to each other, this option allows you to gather them in blocks of up to 100 registers, or 1600 bits.

Installing of this parameter must be approached with caution, since not all devices support access to the registers between fragments.

• Using the multi-items writing functions (15, 16). Instead one-item writing will be used the multi-items functions.
• Asynchronous write. Enables asynchronously writing of the changes to the controller, in the general acquisition cycle and after the data acquisition itself, blocking of reading the written values on one cycle (before the writing buffer clearing).

This mode also prevents for lost the writing data at the connection loss and the wrote data will be transmitted just the connection will be restored.

• Omit cycles for read back of written. Can be useful for PLC which applying the changes not fast and they are processed in some significant time depending on the PLC load. So, the cycles value then specifies count of the omitting read cycles before reading back the changed value, preventing the value twinkle.
• Timeout of connection in milliseconds. Specifies the time interval during which the answer is expected. If there is zero waiting time the transport waiting time by default is used. Allows taking into account individual properties of the controller in the common network.
• Timeout of restore in seconds. Specifies the time interval after which the re-attempt of the request to previously inaccessible device is done.
• Request tries for the protocols RTU and ASCII. Indicates the number of attempts by the repetition of the request in case of incomplete or damaged answer.
• Maximum size of the request block in bytes, useful for controllers with such limits.

3.2 Parameters

The data acquisition module provides two types of parameter: "Standard (Prm)" and "Logical (PrmL)". Additional configuration fields of the parameters of this module are:

• Standard (Prm):
  • Attributes list — contains a structured list of configuration for the attributes ModBUS.
• Logical (PrmL):
  • Parameter template — address of the DAQ-parameter template.

3.2.1 Standard (Prm)

Main page of configuration parameters of the standard type is shown in Figure 9.

Рис.9. Вкладка конфігурації параметру стандартного типу.

Лінія атрибуту у параметрі переліку атрибутів записується як "{dt}:{numb}[:{flg}[:{id}[:{name}]]]".
Де:

• dt — тип даних ModBus ("R"—регістр[3,6(16)], "C"—біт[1,5(15)], "RI"—регістр входу[4], "CI"—біт входу[2]);

"R" та "RI" можуть бути розширені суфіксами: "i2"—Int16, "i4"—Int32, "i8"—Int64, "u2"—UInt16, "u4"—UInt32, "f"—Float, "d"—Double, "b5"—Біт5, "b"—Біт у адресі, "s[КОДУВАННЯ]"—Рядок (розмір по умовчанню 10 та до 100 регістрів);

• numb — адреса ModBus пристрою (десяткова, шістнадцяткова або вісімкова) [0...65535];
• flg — прапорці: режим запису/читання (r-читати, w-писати), суворий режим запиту (без комбінування) 's', інверсія порядку регістрів '~', перемикання порядку байтів 'e' регістрів (у LE загалом та BE для рядків);
• id — ідентифікатор атрибуту що створюється;
• name — ім'я атрибуту що створюється.

Приклади:

"R:0x300:rw:var:Variable" — доступ до регістру;

"C:100:rw:var1:Variable 1" — доступ до біту;

"R_f:200:r:float:Float", "R_f:200:r~:float:Float" — отримати реальне з регістрів 200 та 201, 201 та 200;

"R_i4:400,300:r:int32:Int32" — отримати int32 з регістрів 400 та 300;

"R_b10:25:r:rBit:Reg bit", "R_b:25.10:r:rBit:Reg bit" — отримати біт 10 з регістру 25;

"R_s:15,20:r:str:Reg blk" — отримати рядок (блок регістрів) з регістру 15 та розміром 20.

Лінія, що починається з символу '#', вважається коментарем та не обробляється.

Відповідно до визначеного переліку атрибутів здійснюється опитування та створення атрибутів параметру (рис.10).

Рис.10. Вкладка атрибутів параметру стандартного типа.

3.2.2 Logical (PrmL)

Main page of configuration parameters of the logical type is shown in Figure 11.

Рис.11. Вкладка конфігурації параметру логічного типа.

Значення посилання при конфігурації шаблону (рис.12) записується у формі "{dt}:{numb}[:{flg}]".
Де:

• dt — тип даних ModBus ("R"—регістр[3,6(16)], "C"—біт[1,5(15)], "RI"—регістр входу[4], "CI"—біт входу[2]);

"R" та "RI" можуть бути розширені суфіксами: "i2"—Int16, "i4"—Int32, i8-Int64, u2-UInt16, u4-UInt32, "f"—Float, "d"—Double, "b5"—Біт5, "b"—Біт у адресі, "s[КОДУВАННЯ]"—Рядок (розмір по умовчанню 10 та до 100 регістрів);

• numb — адреса даних ModBus пристрою (десяткова, шістнадцяткова або вісімкова) [0...65535];
• flg — прапорці: режим запису/читання (r-читати, w-писати), інверсія порядку регістрів '~', перемикання порядку байтів 'e' регістрів (у LE загалом та BE для рядків).

Приклади:

"R:0x300:rw" — доступ до регістру;

"C:100:rw" — доступ до біту;

"R_f:200:r", "R_f:200:r~" — отримати реальне з регістрів 200 та 201, 201 та 200;

"R_i4:400,300:r" — отримати int32 з регістрів 400 та 300;

"R_b10:25:r", "R_b:25.10:r" — отримати біт 10 із регістру 25;

"R_s:15,20:r" — отримати рядок (блок регістрів) з регістру 15 та розміром 20.

Рис.12. Вкладка "Конфігурація шаблону" параметра логічного типу.

Модулем передбачена особлива обробка низки атрибутів шаблону:

• f_frq — частота обчислення процедури шаблону або час після останнього обчислення (негативне у секундах) для планування за CRON, тільки читання.
• f_start — ознака першого виконання процедури шаблону — запуск, тільки читання.
• f_stop — ознака останнього виконання процедури шаблону — зупинка, тільки читання.
• f_err — помилка параметру, повний доступ. Значення цього атрибуту шаблону потрапляє до атрибуту помилки параметру "err". Записати сюди EVAL для можливості встановлення ззовні атрибуту "err" та всіх інших у режимі Тільки для Читання.
• SHIFR — значення шифру параметру, тільки читання.
• NAME — значення назви параметру, тільки читання.
• DESCR — значення опису параметру, тільки читання.
• this — об'єкт даного параметру, дозволяє отримати доступ до атрибутів параметру, наприклад, для доступу до архівів-історії.

Відповідно до шаблону, який лежить у основі параметру, ми отримаємо набір атрибутів параметру (рис.13).

Рис.13. Вкладка атрибутів параметру логічного типу.

3.3 API користувацького програмування

У зв'язку із підтримкою параметрів логічного типу, має сенс надання низки функцій користувацького API для їх виклику із шаблону логічного параметру.

Об'єкт "Контролер" [this.cntr()]

• string messIO(string pdu) — відправка PDU pdu через транспорт об'єкту контролеру за посередництвом ModBus протоколу. PDU результату запиту розташовується замість запиту у pdu, а помилка повертається у результаті функції.

Об'єкт "Параметр" [this]

• bool attrAdd( string id, string name, string tp = "real", string selValsNms = "" ) [для включеного параметру логічного типу] — додання атрибуту id з ім'ям name та типом tp. Якщо атрибут вже присутній то будуть застосовані властивості, які можливо змінити "на ходу": ім'я, режим вибору та параметри вибору.
  • id, name — ідентифікатор та ім'я нового атрибуту;
  • tp — тип атрибута [boolean | integer | real | string | text | object] + режим вибору [sel | seled] + тільки для читання [ro];
  • selValsNms — два рядки зі значеннями у першому та їх іменами у другому, поділені ";".
• bool attrDel( string id ) [для включеного параметру логічного типу] — видалення атрибуту id.

4 Посилання

• Діаграма: Об'єктна модель користувача модуля ModBus.