Сети‎ > ‎

Modbus(укр)

6. МЕРЕЖІ MODBUS

MODBUS розроблений в 1979 р. фірмою Modicon Gould (зараз в складі Schneider Electric). Це один із найстаріших протоколів промислової мережі, який на сьогоднішній день є одним з найбільш популярних. Основна причина такої популярності – це простота в реалізації. Даний розділ присвячений мережам, які базуються на протоколі прикладного рівня MODBUS.

На сьогоднішній день MODBUS підтримує і розвиває організація MODBUS-IDA, яка являє собою групу незалежних споживачів та поставників пристроїв автоматизації. Вона забезпечує відкритість даного протоколу та розробляє готові компоненти для спрощення реалізації. Будемо розглядати MODBUS таким, яким він існує на сьогоднішній день в стандартах MODBUS-IDA. Одна з реалізацій протоколу - MODBUS TCP/IP увійшла в стандарти МЕК IEC 61158-5-15,  IEC 61158-6-15 та IEC 61784-2 як 15-й тип. Враховуючи особливості реалізації мереж на базі  MODBUS та опису його в МЕК тільки на прикладному рівні, є доцільним розглядати його в контексті моделі OSI а не МЕК.

6.1. Мережі MODBUS в контексті моделі OSI

Згідно стандартів MODBUS-IDA – MODBUS являється протоколом прикладного рівня для зв’язку типу Клієнт-Сервер між прикладними Процесами пристроїв, які під’єднані до різноманітних типів шин або мереж. В контексті OSI-моделі, ці мережі мають архітектуру, наведену на рис.6.1.

Як видно з рисунка, MODBUS на сьогоднішній день представлений 4-ма мережами: MODBUS RTU, MODBUS ASCII, MODBUS Plus і MODBUS TCP/IP. Перші реалізації MODBUS базувалися на послідовних інтерфейсах з двома режимами передачі RTU і ASCII, але з розвитком комп’ютерних мереж і їх інтеграції з промисловими мережами протокол MODBUS адаптували до використання в мережах, що базуються на основі TCP/IP. MODBUS Plus в основному використовується в пристроях Schneider Electric, тому розглядати його не будемо.

6.2. Реалізація MODBUS на прикладному рівні

6.2.1. Формат MODBUS PDU

MODBUS Application Protocol (MBAP MODBUS протокол прикладного рівня) базується на моделі Клієнт-Серверного обміну повідомленнями і визначає формат повідомлень MODBUS PDU (Protocol Data Unit), які мають вигляд наведений на рис.6.2.
Клієнтський прикладний Процес робить повідомлення-запит до серверного Процесу, в якому в полі „код функції” вказує йому на дію, яку необхідно провести. Байти даних вміщують інформацію, яка необхідна для виконання даної функції. Серверний прикладний Процес у випадку вдалого виконання цієї функції повторює код функції у відповіді (якщо запит передбачає відповідь).
При виникненні помилки, код функції у відповіді модифікується (старший біт виставляється в 1) а в байтах даних передається причина помилки. Тобто, якщо при передачі клієнтським прикладним Процесом повідомлення-запиту з функцією 0316 (000000112) виникла помилка у її виконанні Сервером, той відішле відповідь з полем функції рівним 8316(100000112). В доповненні до зміни коду функції, при помилці, Сервер розміщує в поле даних унікальний код, який вказує на тип і причину помилки.
Код функції являє собою поле з одного байту, яке може приймати значення від 1 до 255 (коди 128-255 зарезервовані під коди повідомлень-відповідей при помилкових діях). Всі коди функцій в MBAP діляться на (див рис.6.3):

-         Public Function Codes – це публічні коди, які описані в стандарті MODBUS-IDA, список яких включає в себе вже назначені та використовувані коди, а також коди для майбутнього використання;

-         User-Defined Function Codes (65-72, 100-110) – це коди, які можуть використовуватись компаніями для власних функцій і не описані в специфікації;

-         Reserved Function Codes (9, 10, 13, 14, 41, 42, 43, 90, 91, 125, 126 і 127) – це зарезервовані коди, які не доступні для загального використання. 

Нижче розписані тільки ті функції, які призначені для доступу до даних процесу. Ці дані, з точки зору MODBUS функцій діляться на:

- Discrete Inputs: дискретні входи, тільки для читання;

- Coils: котушки, внутрішні біти або дискретні виходи, читання/запис;  

- Input Registers: вхідні 16-бітні змінні, тільки читання;

         - Holding Registers: внутрішні/вихідні 16-бітні змінні, читання/запис.

У повідомленні-запиті за полем коду функції можуть слідувати дані, які уточнюють або доповнюють функцію допоміжними даними. Це можуть бути адреси змінних, їх кількість, лічильник байтів даних та самі дані для запису. Для певних функцій, поле даних може бути відсутнім взагалі. Максимальна довжина повідомлення прикладного рівня рівна 253.

6.2.2. Формат основних функцій

Повний список кодів а також специфікацію протоколу можна знайти на офіційному Веб сайті MODBUS-IDA - www.MODBUS.org. В посібнику детально розглянемо тільки найбільш вживані функції MODBUS для обміну даними процесу. Номер функції дається в шістнадцятковому форматі. Скорочення в дужках Hi та Lo що  вказують відповідно на старший та молодший байти. Тобто, якщо для вказівки адреси початкової змінної необхідно двобайтове слово, то значення старшого байта буде передаватись в полі з позначенням Hi, а молодшого – відповідно Lo.

6.2.2.1. Код функції 0116 − читання статусу Coils (дискретних вихідних бітів). Повідомлення-запит вміщує адресу початкового біту і кількість бітів для читання. Біти нумеруються починаючи з 0. У повідомленні-відповіді кожне значення змінної передається одним бітом, тобто в одному байті пакується статус 8 бітових змінних. Якщо кількість їх не кратно восьми, інші біти в байті заповнюються нулями. Лічильник вміщує кількість байт в полі даних.
 

Запит:                                                          

Код функції

01

Адреса початкового біту (HI)

0 до FFFF16

Адреса початкового біту (LO)

Кількість біт (HI)

1 до 7D016 (2000)

Кількість біт (LO)

Відповідь:

 

код функції

01

лічильник байт

N

Значення бітів (перші 8 біт)

0 до FF16

Значення бітів (наступні 8 біт)

0 до FF16

...

 

Значення бітів (N-ні 8 біт)

0 до FF16

 

 

 

 

 

6.2.2.2. Код функції 0216 − читання статусу дискретних входів. Формат даного запиту такий же як попереднього, за винятком поля функції.

6.2.2.3. Код функції 0316  − читання значення вихідних/внутрішніх регістрів. Повідомлення-запит вміщує адресу початкового вихідного/внутрішнього регістру (двохбайтове слово), і кількість регістрів для читання. Регістри нумеруються починаючи з 0.

Запит:                                        

код функції

03

Адреса початкового регістру (Hi)

від 0 до FFFF16

Адреса початкового регістру (Lo)

Кількість регістрів (Hi)

від 1 до 7D16 (125)

Кількість регістрів (Lo)

 

Відповідь:

код функції

01

лічильник байт

N*2

Значення 1-го регістру (Hi)

0 до FFFF16

Значення 1-го регістру (Lo)

...

 

Значення N-го регістру (Hi)

0 до FFFF16

Значення N-го регістру (Lo)

 

 

 

 

 

У відповідному повідомленні в полі даних кожний регістр передається двома байтами.

6.2.2.4. Код функції 0416  читання значення вхідних регістрів. Формат даного запиту такий же як попереднього, за винятком поля функції.

6.2.2.5. Код функції 0516 − запис вихідного/внутрішнього біту. В запиті вказується номер бітової змінної та значення: 0 – 0000, а 1 – FF00, всі інші значення не міняють стан змінних. В широкомовній передачі клієнтський запит виставляє значення даної змінної для всіх серверів.

Функція

05

Адреса біту (Hi)

від 0 до FFFF16

Адреса біту (Lo)

Значення біту (Hi)

0000 або FF0016

Значення біту (Lo)

Нормальна відповідь серверу являється повторенням запиту до клієнта.

6.2.2.6. Код функції 0616 − запис вихідного/внутрішнього регістру. Функція аналогічна попередній, але оперує з регістрами(словами). В запиті вказується номер вихідного/внутрішнього регістру та його значення. В широкомовній передачі запит виставляє значення даної змінної для всіх серверів.

Функція

06

Адреса регістру (Hi)

від 0 до FFFF16

Адреса регістру (Lo)

Значення регістру (Hi)

від 0 до FFFF16

Значення регістру (Lo)

Нормальна відповідь сервера являється повторенням запиту клієнту.

6.2.2.7. Код функції 0F16 − запис декількох вихідних/внутрішніх бітів. В запиті вказується початкова адреса біту, кількість біт для запису, лічильник байтів і безпосередньо значення. В широкомовній передачі біти записуються всім серверам. Розглянемо приклад для встановлення наступних бітових вихідних/внутрішніх змінних:

Байт 1

Байт 2

26

25

24

23

22

21

20

19

--

--

--

--

--

--

28

27

1

1

0

0

1

1

0

1

 

 

 

 

 

 

0

1

В таблиці показана відповідність адреси змінної, починаючи з 19-ї, і значення біту. Для зручності біти розміщені у тому порядку, що і передаються. В другому байті корисні тільки 2 перші біти, значення інших не буде прийнято до уваги, оскільки кількість бітів вказані у кадрі. Запит та відповідь будуть мати такий вигляд:

Запит:                                                 

Функція

0F

Адреса початкового біту (Hi)

00

Адреса початкового біту (Lo)

13

Кількість бітів (Hi)

00

Кількість бітів (Lo)

Лічильник байтів

02

Дані(змінні 19-26)

CD

Дані(змінні 27-28)

01

Відповідь:

Функція

0F

Адреса початкового біту (Hi)

00

Адреса початкового біту (Lo)

13

Кількість бітів (Hi)

00

Кількість бітів (Lo)

 

 

 

 

6.2.2.8. Код функції 1016 − запис декількох вихідних/внутрішніх регістрів.

Запит:                                                                    

Функція

1016

Адреса початкового регістру (Hi)

0 до FFFF16

Адреса початкового регістру (Lo)

Кількість регістрів (Hi)

1 до 007B16 (123)

Кількість регістрів (Lo)

Лічильник байтів

2*N

Дані (1-й регістр Hi)

0 до FFFF16

Дані (1-й регістр Lo)

...

 

Дані (N-й регістр Hi)

0 до FFFF16

Дані (N-й регістр Lo)

Відповідь:

Функція

10

Адреса початкового регістру (Hi)

0 до FFFF16

Адреса початкового регістру Lo

Кількість регістрів (Hi)

1 до 007B16 (123)

Кількість регістрів (Lo)

 

 

 

 

 

6.2.2.9. Повідомлення про помилки. Ці повідомлення стосуються всіх типів MODBUS, але першопочатково були визначені для MODBUS Serial (RTU/ASCII).

При запиті Клієнта до Серверу, можуть мати місце наступні ситуації:

-       якщо Сервер прийняв запит без комунікаційних помилок, і може нормально розпізнати запит, він повертає нормальну відповідь;

-       якщо Сервер не прийняв запит, відповідь не повертається. Клієнт очікує відповіді протягом певного тайм-ауту;

-       якщо Ведений (для MODBUS Serial) прийняв кадр, але знайшов комунікаційну помилку (паритет, помилка контрольної суми), то кадр-відповідь не повертається, а Ведучий чекає відповіді на запит протягом певного тайм-ауту;

-       якщо Сервер прийняв запит без комунікаційної помилки, але не може виконати замовлену функцію (наприклад, читання не існуючих виходів або регістрів),  Сервер повертає повідомлення про помилку і її причини.

Повідомлення про помилку має два поля які відрізняються від полів нормальної відповіді:

ПОЛЕ КОДУ ФУНКЦІЇ: при нормальній відповіді сервер повертає в цьому полі той номер функції, який потребував клієнт. У всіх кодах функції старший біт встановлений в 0. При поверненні повідомлень про помилку, Сервер встановлює цей біт в 1, по чому Клієнт може ідентифікувати наявність помилки.

ПОЛЕ ДАНИХ: В цьому полі при помилці повертається її код.

Таблиця 6.1

Список кодів

Код

Назва

Опис

01

ILLEGAL FUNCTION

Прийнятий код функції не може бути оброблений на Сервері

02

ILLEGAL DATA ADDRESS

Адреса даних вказана в запиті не доступна даному Серверу .

03

ILLEGAL DATA VALUE

Величина, вміщена в полі даних запиту являється не допустимою величиною для Серверу .

04

SLAVE DEVICE FAILURE

Невиправна помилка мала місце поки Сервер намагався виконати дію запиту.

05

ACKNOWLEDGE

Сервер прийняв запит і обробляє його, але необхідний певний час. Ця відповідь захищає Клієнта від генерації помилки тайм-ауту. 

06

SLAVE DEVICE BUSY

Сервер зайнятий обробкою команди, Клієнт повинен повторити запит пізніше.

07

NEGATIVE ACKNOWLEDGE

Невдалий програмний запит (для функцій 13 і 14).

08

MEMORY PARITY ERROR

Сервер хоче читати розширену пам’ять, але знайшов помилку паритету.

 

Приклад 6.1. MODBUS. Запит на читання статусу вихідних бітів.

Завдання. Сформувати повідомлення-запит та повідомлення-відповідь на читання вихідних/внутрішніх бітів з 20 по 39 при: обробці без помилок; обробці з помилкою ILLEGAL DATA ADDRESS.

Рішення. Формат повідомлень показаний на рис.6.4. Слід зауважити, що 1-й біт в адресному просторі MODBUS опитується під номером 0. Тому 20-й біт зчитується під номером 19. Деталі читайте в  6.2.3.

Приклад 6.2. MODBUS. Запит на читання значення вихідних/внутрішніх регістрів.

Завдання. Сформувати повідомлення-запит та повідомлення-відповідь на читання вихідних/внутрішніх регістрів починаючи з 108-го по 110-й при позитивній обробці запиту Сервером.

Рішення. Формат повідомлень показаний на рис.6.5. Як і в попередньому випадку 108-й регістр в запиті вказується під номером 107 (6В16)
 

6.2.3. Адресна модель MODBUS та доступ до даних

Всі змінні до яких звертається клієнтський прикладний Процес являються частиною області пам’яті пристрою. Однак фізичні адреси цих змінних можуть не співпадати з тими, до яких він звертається згідно протоколу. Головне, щоб ці змінні були відображенням (mapping) дійсних даних в пристрої. На рис.6.6 показаний процес обробки запитів на стороні серверу MODBUS. Як видно з рисунку, при зверненні до певної змінної по її номеру, наприклад на читання,  по суті йде звернення до певної області даних в прикладній програмі пристрою. Зв’язок даних MODBUS моделі з фізичними даними називають відображенням (mapping).

Слід відмітити, що мінімальна адреса елементу даних моделі MODBUS дорівнює 1 а не 0.

Таке розмежування між фізичною структурою даних і MODBUS моделі даних дає можливість адаптувати протокол під структуру різних пристроїв. Для прикладу, в стандарті наводяться два популярні способи реалізації MODBUS моделі даних: розділення даних по блокам (рис.6.7) та використання доступу до даних одного і того ж блоку (рис.6.8). Як видно з рисунків модель даних з єдиним блоком дає доступ до одних і тих же фізичних даних. Тобто області Input та Holding регістрів співпадають, а області Digital Inputs та Coils теж співпадають і знаходяться в області регістрів.

 Приклад 6.3. MODBUS. Модель даних для різних типів пристроїв.

Завдання. Показати відображення даних моделі MODBUS на адресний простір Momentum/Quantum (Schneider Electric),  Micro/Premium/M340/Twido(Schneider Electric), Vipa CPU-21xSER1 (VIPA) Vipa IM-253NET(VIPA).

Рішення. Для контролерів Schneider Electric гілки Modicon тобто Momentum та Quantum, MODBUS – це рідний протокол, тому модель даних  MODBUS абсолютно співпадає з моделлю їх адресного простору. Нумерація змінних починається з 1-ї (0-вий номер в запиті звертається до 1-ї змінної)

Для контролерів Micro/Premium, які влились в Schneider Electric під брендом Telemechanique, а також M340 та Twido доступ надається тільки до внутрішніх змінних (M - Memory), тому різниці між вхідними та вихідними бітами та регістрами немає, однак бітова область не співпадає з регістровою. Тобто Сервер MODBUS цих ПЛК будуть однаково реагувати скажімо на функції 01 та 02, або 03 та 04. Нумерація змінних починається з 0-ї (0-вий номер в запиті звертається до 0-ї змінної, тобто %M0-біт, або %MW0 – регістр). Таким чином загальна таблиця відображення даних для різних ПЛК від Schneider Electric має наступний вигляд:

 

Momentum/Quantum

Micro/Premium/M340/ Twido

Input Discrete

1XXX

%M

Coils

0XXX

%M

Input Registers

3XXX

%MW

Holding Registers

4XXX

%MW

 Для Siemens-подібних контролерів VIPA мережі MODBUS не являються найбільш вживаними. Тим не менше VIPA випускає номенклатуру модулів з підтримкою даного протоколу. Зокрема в процесорних модулях типу Vipa CPU-21xSER1, є вбудований послідовний порт з підтримкою MODBUS Serial (RTU/ASCII) як в режимі Ведучого так і Веденого. Модуль представляє бік Серверу MODBUS- в режимі Веденого (пояснення дивись в MODBUS Serial), тому саме в цьому режимі розглядається відображення даних моделі MODBUS. При конфігурації послідовного порту CPU-21xSER1, задається його режим (MODBUS Master). Далі, весь обмін проходить через вхідні та вихідні буфери (рис.6.9), які прикладна програма повинна поновлювати самостійно. Однак буферів всього два, а отже бітові змінні знаходяться в пам’яті регістрових, вхідні в області вхідних регістрів, вихідні – вихідних (див.рис.6.10).
Слід зазначити, що буфери являються внутрішньою пам’яттю комунікаційного порту, а не самого ПЛК. Для відображення буферів на області пам’яті ПЛК, в комунікаційних функціях SEND та RECEIVE вказується необхідна область пам’яті, як правило це DB-область. Необхідно також пам’ятати, що адресація даних в буферах з боку мережі проходить по словам, а з боку програми до DB ПЛК – по байтам.

Інтерфейсний модуль Vipa IM-253NET(VIPA) для побудови розподілених систем вводу/виводу на базі Ethernet підтримує MODBUS TCP/IP тобто може бути Сервером MODBUS (Клієнтом бути не може). Доступ до входів та виходів системи на базі інтерфейсного модуля відбувається аналогічно, як показано на рис.6.10. Буфер IN поновлюється модулем автоматично, а виходи ПЛК автоматично відновлюються даними з буферу OUT.

6.3. MODBUS Serial

Перші мережі MODBUS базувалися на асинхронних послідовних лініях зв’язку і отримали назву MODBUS RTU та MODBUS ASCII. На фізичному рівні вони використовують стандартні послідовні інтерфейси з символьним режимом передачі (див. рис.6.1).

На сьогоднішній день в MODBUS-IDA ці мережі отримали назву MODBUS over Serial Line і описані у відповідному стандарті. У ньому вказуються правила та рекомендації використання на канальному та фізичному рівні.

Оскільки мережа MODBUS RTU/ASCII може мати шинну топологію, то визначений метод доступу до шини − це модель Ведучий/Ведений. В мережах MODBUS RTU та MODBUS ASCII Процес Ведучого завжди являється Клієнтом, а Процеси Ведених – Серверами. Це значить, що Ведучий відсилає запити, а Ведені їх обробляють. Цей запит може бути адресований як індивідуальному вузлу так і всім Веденим на шині (broadcast).

На канальному рівні MODBUS RTU/ASCII використовується адресація орієнтована на ідентифікатори вузлів. Кожний Ведений повинен мати свою унікальну адресу (1-247), Ведучий не адресується.. При індивідуальних запитах, Ведучий з клієнтським Процесом формує кадр із повідомленням-запитом і відправляє його за вказаною адресою. Ведений з серверним Процесом отримує цей кадр і обробляє повідомлення. Після його обробки Ведений формує кадр з повідомленням-відповіддю і відправляє його назад Ведучому. Кадр з повідомленням-відповіддю носить також функції кадру підтвердження, який Ведучий буде чекати від Веденого протягом часу, визначеного тайм-аутом.

При широкомовних запитах (broadcast) використовується 0-ва адреса. Широкомовні запити не потребують підтвердження, тому після відправки широкомовного кадру Ведучий не очікує кадр відповіді.

6.3.1. Канальний рівень

На рис.6.11 показаний загальний вигляд кадру MODBUS Serial. Зверніть увагу, що розмежування між кадрами та тип контрольної суми тут не вказано, оскільки це залежить від режиму передачі ASCII або RTU. В полі адреси пристрою Ведучий при запиті вказує адресу отримувача, а Ведений при відповіді - свою адресу. Поля MODBUS PDU описані вище.

На часовій діаграмі рис.6.12 показані три типові ситуації роботи моделі Ведучий/Ведений на MODBUS Serial. Перша ситуація – типовий обмін в одноадресному режимі, друга – в широкомовному, третя – реакція Веденого на комунікаційну помилку.

6.3.2. MODBUS RTU

Даний режим передбачає використання 8 біт даних в 11-бітному символі, що дозволяє передавати по байту на символ. Формат символу в RTU режимі:    1 стартовий біт;  8 біт даних (молодший біт передається першим); 1 біт паритету + 1 стоповий біт або без паритету + 2 стопових біта.

Формат кадру MODBUS RTU наведений на рисунку 6.13. Розмежування між кадрами проводиться за допомогою пауз між символами. Новий кадр не повинен з’являтися на шині раніше, ніж 3.5*Тс від попереднього, де Тс – час передачі одного символу. Якщо час відсутності сигналу на лінії (інтервал тиші) буде більше ніж 3.5*Тс приймач ідентифікує помилку. З іншого боку, появлення нового кадру раніше ніж 3.5*Тс, теж приведе до помилки.

Поле адреси і коду функції в RTU режимі займають по одному байту, оскільки байти передаються по символу на кожний. В якості контрольної суми використовується два байти, обраховані по алгоритму CRC16.

6.3.3. MODBUS ASCII

У даному режимі кожний байт повідомлення передається як два ASCII символи їх шістнадцяткового представлення, тобто значення байта 0316 буде передаватись як ASCII-код символів „0” і „3” (0110000 0110011) Отже байти даних, код функції і байт поля перевірки буде передаватись кодами символів 0-9, A-F. Формат символу в ASCII-режимі: 1 стартовий біт;  7 бітів даних, молодший біт передається першим; 1 біт паритету + 1 стоповий біт або без паритету + 2 стопових біта.

 Формат кадру наведений на рис.6.14. Як бачимо, для розмежування між кадрами використовуються стартовий символ „:” та стопова послідовність „CR LF”. Приймачі на шині безперервно відслідковують символ „:” який однозначно вказує на початок кадру. Коли він прийнятий, приймачі відловлюють поле адреси і т.д. Це дуже простий спосіб синхронізації, який дозволяє некритично відноситись до пауз між символами (до 1 сек.).  Адреса Веденого та код функції займають по два символи, відповідно до значення одного байта. Далі йдуть n*2 символів даних, де n кількість байтів даних. В ASCII режимі MODBUS для підрахунку контрольної суми використовується алгоритм  LRC. Причому контрольна сума проводиться над усіма байтами кадру, виключаючи стартову та стопову послідовність символів.

Режим ASCII накладає менші вимоги на обладнання за рахунок використання стартової і стопової послідовності в розмежуванні кадрів і нечутливості до значних пауз між символами. Але переваги є і його недоліками. RTU-режим більш вимогливий до інтервалів між кадрами, але значно продуктивніший ніж попередній.

Приклад 6.4. MODBUS. Розрахунок часу опитування Ведених на MODBUS-RTU.

 Завдання. Побудувати кадри форматів повідомлень запитів та відповідей для MODBUS RTU та розрахувати загальний час опитування 10-ти аналогових 16-бітних змінних для 4-х Ведених (рис.6.15). Швидкість передачі даних 19200 біт/с. Клієнтський Процес Ведучого (TSX Premium) та серверні Процеси Ведених (ПЛК TSX Micro ) приймають повідомлення на початку циклу, а відправляють - в кінці циклу. Час циклу Ведучого = 10 мс, Ведених - 5с.
Виконання завдання. Доступ до внутрішніх аналогових змінних TSX Micro проводиться через 03 або 04 функцію, тому формат кадрів буде мати вигляд як на рис.6.16.
 
 

Враховуючи, що структура інших кадрів – аналогічна, наводити їх формат немає сенсу.

Аналогічно рис.6.12 побудуємо часову діаграму обміну (рис.6.17). З боку клієнтської програми повідомлення-запит формується за допомогою комунікаційної функції, відправка даних якої через комунікаційний порт проводиться в кінці циклу задачі, а отримування з порту – на початку циклу. Така поведінка клієнтської сторони цілком відповідає багатьом реалізаціям для різних ПЛК.

В TSX Micro MODBUS-Сервер реалізований на рівні операційної системи. Специфіка реалізації заключається в тому, що прийом MODBUS-запитів з комунікаційного порту системою проводиться на початку циклу, а відправка повідомлень-відповідей – вкінці.

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

На рис.6.17 показано, що надходження кадру приходить десь всередині циклу. Це значить, що їх обробка та генерація відповіді пройде приблизно через 1,5 циклу. Слід розуміти, що це усереднене значення, для найгіршої оцінки краще резервувати 2 часу циклу (тобто коли кадр прийшов відразу після опитування комунікаційного порту). Таким чином час транзакції для одного ПЛК, наприклад PLC1 (ТТ1),  буде дорівнювати:

ТТ1=С5+T1.req+2*C1+T1.res+C5*2                                                          (6.1)
 

ТТ1 розрахований з урахуванням 2 циклів затрачених Веденим на генерацію відповіді на повідомлення-запит. Якби транзакця проводилась не періодично, як по умові задачі, а по виникненню події, то в час транзакції необхідно б було включити також ще один цикл Ведучого. Нескладно вивести час опитування всіх Ведених:

ТТall=C5*9+C1*2+C2*2+C3*2+C4*2+T1.req+T1.res+ T2.req+T2.res+ T3.req+T3.res+ T4.req+T4.res             (6.2)

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

ТТall= C5*9 + C1*8 + (T1.req+T2.req)*4                                            (6.3)

Розрахуємо час T1.req та T2.req. Час передачі кадру (Тframe) можна орієнтовно розрахувати по кількості символів (Nsymb) в кадрі та часу передачі одного символу (Tsymb):

Tframe=Nsymb*Tsymb                                                   (6.4)

Час передачі одного символу розраховується:

час передачі одного символу = кількість біт в символі / бітова швидкість;

Час передачі кадрів буде  дорівнювати (див.рис.6.16 та рис.6.17):

T1.req=8*(11/19200)=4,58 мс

T1.res=25*(11/19200)=14,33 мс

TTall=90+40+ (4,58+14,33)*4= 206 мс.

Таким чином, для опитування 10-ти змінних з 4-х Ведених зі швидкістю 19200 біт/с необхідно затратити приблизно 206 мс. Якщо необхідне періодичне опитування бажано зарезервувати певний час, наприклад ще додатково 100 мс.

У ряді випадків реалізація функцій MODBUS-Клієнта лягає на операційну систему, а доступ до них в програмі ПЛК відбувається через інтерфейсні комунікаційні функції. Зокрема це характерно для більшості ПЛК від Scneider Electric (Momentum, Quantum, TSX Micro, TSX Premium, M340). В ряді інших систем – клієнтську сторону на прикладному рівні необхідно повністю прописувати в програмі ПЛК, а інтерфейс надається тільки для обміну з комунікаційним портом. В цьому випадку система надає сервіси відправки та отримання повідомлення (яке формує і аналізує сама програма коритсувача), і генерації та перевірки контрольної суми. Розглянемо приклад.

Приклад 6.5. MODBUS. Реалізація MODBUS-клієнта на TSX Twido.

Завдання. Записати фрагмент програми в TSX Twido для зчитування 3-х регістрів з Веденого з адресою 1 (рис.6.18).

Рішення. У Twido клієнтську сторону MODBUS необхідно реалізовувати через універсальну функцію EXCHx, яка відправляє та/або отримує дані через комунікаційний порт з номером x. Параметрами функції є таблиця слів (%MW), в яких розміщуються дані управління функцією, дані для відправки та буфер для приймання. Якщо обмін буде проходити через комунікаційний порт 2, то виклик функції буде мати такий формат:

EXCH2 %MWy:n,

де y – номер першої змінної виділеної таблиці, n – кількість слів в таблиці.

Формат таблиці, тобто даних, які необхідно заповнити, та область даних для приймання однаковий для всіх типів комунікацій. Для функцій 03/04 (читання

N слів) на  MODBUS-RTU ця таблиця буде мати вигляд наведений у табл.6.2).

Таблиця параметрів складається з 3-х частин-підтаблиць. В таблиці управління функцією задаються параметри для самої функції. Так в старшому байті 0-го  слова вказується що ця функція працює в обидва боки, тобто після відправки даних, необхідно чекати відповіді. Молодший байт цього ж слова вказує на довжину таблиці передачі (в даному випадку 6 байт), для того щоб система знала які байти необхідно передати (з 2-го слова по 4-те) і звідки починається буфер прийому (з 5-го слова). Зміщення в передачі та прийомі необхідно для вирівнювання даних в буферах  по словам.

Таблиця передачі вміщує безпосередньо сам запит, тобто це кадр без коду CRC. Таблиця прийому – це буфер, який система заповнить кадром відповіді, при позитивному результаті. Таким чином, щоб скористатися цією функцією, перед цим необхідно побудувати кадр запиту та відповіді та виключити поля CRC(рис.6.19)

Таблиця 6.2

Таблиця параметрів

 

Індекс у таблиці

Старший байт

Молодший байт

Таблиця управління функцією

0

01 (тип ф-ції віправка+прийом)

06 (довжина таблиці передачі)

1

03 (зміщення в прийомі)

00 (зміщення в передачі)

Таблиця передачі

2

адреса веденого

03 (номер функції)

3

адреса початкового регістру

4

кількість регістрів

Таблиця прийому (повідомлення-відповідь)

5

адреса веденого

03 (номер функції)

6

00 (байт для зміщення)

лічильник байт

7

перший регістр

8

другий регістр

...

N+6

N-ний регістр

 

 Як бачимо, в запиті – 6 байт. Цю кількість необхідно вписати в молодший байт 0-го слова таблиці. У відповіді очікується 9-байт. Якщо байти кадру відповіді розмістити в послідовності слів (в ПЛК Schneider Electric пам’ять адресується словами), то старший байт першого прийнятого регістру (згідно умови %MW100) припаде на молодший байт 2-го слова в буфері, а молодший байт прийнятого регістру припаде на старший байт 3-го слова в буфері. Таким чином всі прийняті слова будуть зміщені, і прочитати їх буде проблематично. Для усунення цієї проблеми в таблиці параметрів функції є поле  зміщення прийому, в якому вказується номер байта в буфері прийому, який буде зсувати всю послідовність.

Заповнивши всі поля, фрагмент програми буде мати вигляд як на рис.6.20.

Верхній ланцюг LD призначений для заповнення таблиці управління функцією та таблиці передачі. 

У другому ланцюзі проводиться безпосередньо виклик функції. Змінна %MSG2.D повертає логічну 1, коли функція EXCH2 оброблена і результат отриманий. Її використання не дає „затопити” мережу надмірною кількістю кадрів, адже поки немає відповіді на попередній запит або не пройшов час тайм-ауту, новий запит відправляти не можна. 

Останній ланцюг призначений для запису результату читання в змінні %MW0:3 (таблиця з 3-х слів починаючи з %MW0). Змінна %MSG2.E буде рівною 1-ці тоді, коли є місце помилки у виклику функції.
 

6.3.4. Реалізація фізичного рівня для MODBUS Serial

На відміну від початкової специфікації, яка обмежувалась описом кадру, в стандарті MODBUS-IDA описуються також правила для реалізації мережі на фізичному рівні. MODBUS over Serial Line базується на використанні послідовних інтерфейсів RS-485, RS-422 та RS-232.

Для  RS-485 визначена топологія – це шина, до якої передбачено три способи підключення пристроїв (рис.6.21):

-         безпосередньо до магістрального (trunk) кабелю, так званим способом daisy-chain;

-         через пасивну коробку підключення та кабель відгалуження (Derivation);

через активну коробку та специфічний кабель відгалуження.

Інтерфейси між кабелями та лементами мережі мають наступні позначення (див. рис.6.21): ITr – інтерфейс до магістрального кабелю; IDv – інтерфейс між пристроєм та пасивною коробкою;  AUI  - інтерфейс між пристроєм та активною коробкою; LT – термінатори лінії.

Бітові швидкості визначені рівними 9600 біт/с та 19200 біт/с (по замовченню). Інші швидкості є опціональними. Використовується метод кодування NRZ.

При використанні RS-485 стандарт визначає правила підключення пристроїв по 2-х провідній та 4-хпровідній схемі, а також правила сумісності 2-х провідних та 4-х провідних інтерфейсів на єдиній лінії. Нижче розглянуте тільки 2-х провідне підключення, яке є обов’язковим.

По суті, 2-х провідне підключення на самому ділі являється 3-х провідним, тому що крім ліній A-(D0) та B+(D1) використовується також загальна лінія C(Common), яка є обов’язковою (рис.6.22).

Загальна кількість пристроїв обмежена: 32 пристрої на одному сегменті RS-485 без репітерів, використання яких дозволяється. Максимальна довжина кабелю залежить від швидкості, кабелю, кількості навантажень через daisy-chain і конфігурації мережі (2-х провідна або 4-х провідна). Для бітової швидкості 9600 і кабелю AWG26 максимальна довжина обмежена 1000м. Кабель відгалуження повинен бути коротше за 20 м. Якщо використовується мультипортова коробка з n портами, то кожен кабель відгалуження обмежений довжиною 40/n м. 

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

Для погашення відбиття хвиль на кінцях лінії між D1 та D0 виставляється термінатори лінії (LT). Термінатори дозволяється виставляти тільки на магістральному кабелі. В якості термінаторів можна використати:

-         резистор номіналом 150 Ом та потужністю 0.5 Вт;

-         послідовно з’єднані конденсатор (1 нФ, 10 В мінімум) та резистор номіналом 120 Ом (0.25 Вт) при використанні поляризації лінії

У стандарті MODBUS Serial визначені правила реалізації захисного зміщення (поляризації), які  передбачають  підключення  живлення  номіналом 5 В між D1 та D0 через PullUp та PullDown резистори для утримання логічної ”1” на лінії при відсутності передачі. Номінал резисторів вибирається від 450 Ом до 650 Ом в залежності від кількості пристроїв (650 Ом при великій кількості). Захисне зміщення проводиться тільки в одній точці лінії, як правило на стороні Ведучого. Максимальна кількість пристроїв з реалізованою поляризацією зменшується на 4 порівняно з системою без поляризації. Поляризація є необов’язковою. Однак ряд пристроїв критично налаштовані на відсутність логічного сигналу. Якщо це так, то поляризацію необхідно реалізовувати самостійно, або використовувати існуючі схеми, якщо такі передбачені пристроями. В іншому випадку пристрої, які потребують поляризації не будуть нормально працювати в мережі. 

Стандарт визначає також механічний інтерфейс, тобто типи роз’ємів, вилок та відповідність сигналів на контактах. В якості механічного терміналу можна використовувати клемну колодку, екранований RJ-45 (рис.6.23) або екранований SUB-D9 роз’єм (рис.6.24).

В таблиці 6.3 вказані призначення контактів для конекторів при 2-х провідному підключенню по RS-485, а в таблиці 6.4 по RS-232 .

  

Таблиця 6.3

Призначення контактів конектора при підключенні по RS-485

номери контактів

вимоги до наявності

контур IDv

контур ITr

назва RS-485

коментар

 (див. розділ 3)

RJ45

SUB-D9

3

3

опціонально

PMC

-

-

управління режимом ком. порту

4

5

обов’язково

D1

D1

B/B'

напруга V1, V1>V0 для лог. "1"

5

9

обов’язково

D0

D0

A/A'

напруга V0, V0>V1 для лог. "0"

7

2

рекомендовано

VP

-

-

+ живлення 5…24 VDC

8

1

обов’язково

Common

Common

C/C'

- живлення та сигнальна земля

 

Таблиця 6.4

Призначення контактів конектора при підключенні по RS-232

DCE (модем)

контур

DTE

номери

контактів

вимоги до наявності

назва

коментар

(див. розділ 3)

джерело

RS-232

вимоги до наявності

номери

контактів

RJ45

SUB-D9

RJ45

SUB-D9

1

2

обов’язково

TxD

Transmitted Data

<< DTE

обов’язково

2

3

2

3

обов’язково

RxD

Received Data

DCE >>

обов’язково

1

2

3

7

опціонально

CTS

Clear to Send

DCE >>

опціонально

6

8

6

8

опціонально

RTS

Request to Send

<< DTE

опціонально

3

7

8

5

обов’язково

Common

Signal Common

-

обов’язково

8

5

 

В якості кабелів для 2-х провідного типу з’єднання стандарт визначає подвійну екрановану виту пару категорій 4 (до 600м) або 5 (до 1000м), де в одній парі йдуть збалансовані сигнали D0 та D1, а в другій – сигнальна земля Common. Рекомендовані кольори кабелів: D1 жовтий; D0 коричновий;  Common сірий.

Приклад 6.6. MODBUS. Схема мережних з’єднань MODBUS RTU.

Завдання. Нарисувати схему мережних з’єднань для 2-х провідної реалізації шини MODBUS RTU з наступними вузлами:

PLC1: VIPA CPU 115SER 6BL32 (Ведучий) через вбудований послідовний порт процесорного модулю;

PLC2: TSX Twido TWDLMDA40DTK (Ведений) через комунікаційний модуль TWD NOZ 485T

PLC3: TSX Twido TWDLMDA40DTK (Ведений) через комунікаційний модуль TWD NOZ 485T

Рішення. На рис.6.25 показана схема мережних з’єднань до поставленої задачі. Специфікація мережних засобів дана в таб.6.5.

Як видно з рис.6.25, PLC1 підключається до шини через пасивну коробку, а вірніше через клемну колодку, що в принципі  рівнозначно. Це спричинено тим, що на ПЛК підключення йде з використанням 9-пінового SUB-D роз’єму, що потребує розробку власного кабелю, схема підключення (спаю) якого до коннектора та до клемної колодки показаний нижче основної схеми.  

Таким чином до вилки КК1 проводи кабелю КМ2 необхідно припаяти. Призначення пін розетки SER не співпадає зі стандартною. Піни 8 та 3, відповідно А(D0) та В(D1) йдуть в одну пару, яка потім підключаються до ХТ1:1 та ХТ1:2, а 5 та 6, відповідно  M5V(-5В) та P5V(+5В) йдуть в іншу виту пару кабелю КМ2. Живлення 5В необхідно для того, щоб реалізувати захисне зміщення (асиметрію) ввідповідно до стандарту, крім того -5В являється сигнальною землею (Common).

Кабель КМ2 підключається до ХТ1 відповідно до схеми, показаної на рис.6.25. Екран кабелю з’єднується з сигнальною землею відповідно до вимог стандарту. Слід нагадати, що ПЛК VIPA в цій системі є Ведучим, отже і захисне зміщення і з’єднання екрана з землею необхідно реалізовувати саме в цьому місці. Захисне зміщення проводиться за допомогою живлення 5В, яке береться з порту SER та двох резисторів.

Таблиця 6.5.

Специфікація мережних засобів

Позна-чення

Найменування

Назва

Кіль-кість

Примітка

1

PLC1

ПЛК VIPA 100

VIPA CPU 115SER 6BL32

1 шт.

VIPA

2

PLC2, PLC3

ПЛК Twido

TWDLMDA40DTK

2 шт.

Schneider Electric

3

MK1, MK2

комунікаційний модуль для реалізації інтерфейсу RS-485, підключення під гвинт

TWD NOZ 485T

2 шт.

Schneider Electric

4

KK1

9-піновий SUB-D коннектор типу вилка

 

1 шт.

 

5

XT1

клемна колодка на 4 клеми

 

1 шт.

 

6

TL1,TL2

термінатори лінії

 

2 шт

виготовляються з поз. 7 та 8

7

Rt

Резистор 120 Ом (0.25 Вт)

 

2 шт.

у складі поз.6

8

Ct

Конденсатор 1 нФ ( >10 В)

 

2 шт.

у складі поз.6

9

Ru,Rd

Резистор 500 Ом (0.25 Вт)

 

2 шт

 

10

КМ1

кабель подвійна екранована вита пара 5-ї категорії AWG26

 

300 м

 

11

КМ2

кабель подвійна екранована вита пара 5-ї категорії AWG26

 

2 м

 

12

КМ3

кабель подвійна екранована вита пара 5-ї категорії AWG26

 

300 м

 

 

PLC2 та PLC3 з’єднуються з шиною за допомогою комунікаційного модулю з клемною колодкою. Це дозволяє реалізувати підключення типу daisy-chain. Однак на колодці не передбачене місце підключення екрану, тому кабель екранується окремо. Слід нагадати, що екранування дозволяє вирівняти потенціали на різних кінцях кабелю (див. розділ 3).  

Термінатори ліній реалізовані послідовним з’єднанням резистору та конденсатору, оскільки на шині задіяне захисне зміщення.

 

На сьогоднішній день MODBUS Serial використовується як на рівні контролерів так і на рівні датчиків (для розподіленої периферії). Його використання проблематичне при наявності на шині декількох диспетчерських пристроїв, які в Клієнт-Серверній архітектурі повинні бути Клієнтами, адже на MODBUS RTU/ASCII тільки Ведучий може бути Клієнтом. Але навіть в такій ситуації є можливість організувати доставку даних всім потребуючим вузлам, якщо вони підтримують такий режим.

Виходячи з вказаного, на шині MODBUS Serial можна зупинити свій вибір у випадку, якщо:

-       всі пристрої-Сервери підтримують MODBUS RTU/ASCII в режимі Веденого;

-       необхідний тільки один пристрій-Клієнт, якому необхідно ініціювати обміни на шині, який підтримує MODBUS RTU/ASCII як Ведучий;

-       швидкість відновлення даних задовольняє умову задачі;

-       немає необхідності в приоритетних повідомленнях (телеграмах);

-       не ставляться особливі вимоги до надійності шини.

Альтернативою MODBUS RTU/ASCII є MODBUS TCP/IP, який дуже швидко став популярним і немає тих недоліків, які наведені вище.

 
Оставить комментарии Вы можете здесь http://pupena-san.blogspot.com 
  
MODBUS TCP -> Modbus/TCP(укр)
Подстраницы (1): Modbus/TCP(укр)
Comments