From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Modules/ModBus and the translation is 100% complete.

Other languages:
English • ‎mRussian • ‎Українська
Модуль Ім'я Версія Ліцензія Джерело Мови Платформи Тип Автор
ModBus ModBus 3.8 GPL2 daq_ModBus.so en,uk,ru,de x86,x86_64,ARM Збір Даних Роман Савоченко
Опис
Надає реалізацію клієнтського ModBus сервісу. Підтримуються Modbus/TCP, Modbus/RTU та Modbus/ASCII протоколи.
ModBus ModBus 2.10 GPL2 daq_ModBus.so en,uk,ru,de x86,x86_64,ARM Протокол Роман Савоченко
Опис
Надає реалізацію ModBus протоколів. Підтримуються Modbus/TCP, Modbus/RTU та Modbus/ASCII протоколи.
-

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

Підмножина Діапазон кодів
Стандартні 1-21
Резерв для розширених функцій 22-64
Користувацькі 65-119
Резерв для внутрішніх потреб 120-255

Модулем збору даних використовуються команди 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 — ознака останнього виконання — зупинки програми.

At.png Оскільки у вказівнику розширених типів регістрів може використовуватися недозволений символ ',' то доступ до нього із програми можна здійснити тільки альтернативним способом, через об'єкт "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).

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

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

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

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

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

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

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

За допомогою цієї вкладки можна встановити:

  • Стан об'єкту контролеру, а саме: Статус, "Ввімкнено", "Виконується" та ім'я сховища, яке містить конфігурацію.
At.png Ручний перезапуск ввімкненого об'єкту контролеру викликає примусове переформування блоків збору.
  • Ідентифікатор, ім'я та опис контролеру.
  • Стан "Ввімкнено" та "Виконується", у який переводити об'єкт контролеру при завантажені.
  • Політика планування та пріоритет задачі збору даних.
  • ModBus протокол, який використовується для опитування фізичного пристрою (TCP/IP, RTU або ASCII).
  • Адреса вихідного транспорту із використанням уніфікованого підключення із навігацією. Типовий порт ModuBus/TCP це 502. Поле може бути встановлено у порожнє та змінено під час виконання. Формат адреси:
    • "{TrModule}.[out_]{TrID}[:{TrAddr}]" — типовий вихідний із автоматичним створенням TrID за його відсутності та наданні TrAddr;
    • "{TrModule}.in_{TrID}:{RemConId}" — ініціативний вхідний із ідентифікатором підключення у RemConId.
  • ModBus вузол призначення. У випадку з протоколами RTU та ASCII це індивідуальна адреса фізичного пристрою, а для TCP/IP це ідентифікатор одиниці.
  • Об'єднання фрагментів регістрів. Стандартні функції 1-4 дозволяють запитати одразу декілька суміжних регістрів або бітів. Така стратегія часто дозволяє оптимізувати трафік та час. Однак, потрібні регістри не завжди розташовані суміжно один до одного та така опція дозволяє збирати їх у блоки до 100 регістрів або 1600 бітів.
At.png До встановлення цього параметру треба підходити з обережністю, оскільки не всі пристрої підтримують доступ до регістрів між фрагментами.
  • Використовувати функції запису декількох елементів (15, 16). Замість функцій одно-елементного запису буде використано багато-елементні.
  • Асинхронний запис. Вмикає асинхронний запис змін до контролеру, у загальному циклі опитування та після самого опитування даних, блокуючи читання записаних значень на один цикл (до очищення буферу запису).
At.png Цей режим також запобігає втраті записаних даних за втрати підключення та записані дані будуть передані щойно підключення буде відновлено.
  • Пропуск циклів для читання назад записаного. Може бути корисним для ПЛК, що застосовують зміни не швидко та вони опрацьовуються за певний значний час, залежно від навантаження ПЛК. Тож, значення циклів визначає кількість циклів читання, що пропускаються перед зворотнім читанням зміненого значення, запобігаючи блиманню значення.
  • Час очікування підключення у мілісекундах. Вказує проміжок час, на протязі якого очікувати відповіді. У випадку вказання нульового значення використовується час очікування по замовченню у транспорті. Дозволяє враховувати індивідуальні властивості контролеру у загальній мережі.
  • Час відновлення підключення у секундах. Вказує проміжок часу, за вичерпанням якого здійснювати повторну спробу запиту до раніш недоступного пристрою.
  • Спроб запиту для протоколів RTU та ASCII. Вказує на кількість спроб повтору запиту у випадку отримання неповної або пошкодженої відповіді.
  • Максимальний розмір блоку запиту у байтах, корисний для контролерів з таким обмеженням.

3.2 Параметри

Модуль збору даних надає два типи параметру: "Стандартний (Prm)" та "Логічний (PrmL)". Додатковими конфігураційними полями параметрів цього модуля є:

  • Стандартний (Prm):
    • Перелік атрибутів — містить структурований перелік конфігурації атрибутів ModBUS.
  • Логічний (PrmL):
    • Шаблон параметру — адреса шаблону параметру DAQ.

3.2.1 Стандартний (Prm)

Головну сторінку конфігурації параметру стандартного типу представлено на рисунку 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 Логічний (PrmL)

Головну сторінку конфігурації параметру логічного типу представлено на рисунку 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 для їх виклику із шаблону логічного параметру.

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

Об'єкт "Контролер" [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 Посилання