Сети‎ > ‎Modbus(укр)‎ > ‎

Modbus/TCP(укр)

<-На початок  Modbus(укр)

6.4.MODBUS TCP/IP

6.4.1. Комунікаційна архітектура MODBUS TCP/IP

Мережа MODBUS TCP/IP базується на стеку протоколів TCP/IP і перш за все призначена для роботи на базі мереж Ethernet. MODBUS TCP/IP описаний в специфікаціях MODBUS-IDA, в яких комунікаційна система MODBUS TCP/IP може включати різні типи пристроїв (рис.6.26):

-       MODBUS TCP/IP Клієнти і Сервери підключені до TCP/IP мережі;

міжмережні пристрої типу мостів, маршрутизаторів або шлюзів для з’єднання TCP/IP мережі з послідовними лініями підмереж,  що дозволяє обмінюватися даними MODBUS Serial Клієнтськими і Серверними пристроями.
Таким чином комунікаційна система MODBUS TCP/IP дозволяє обмінюватися пристроям не тільки на мережах зі стеком  TCP/IP, а і з пристроями на послідовних лініях зв’язку (MODBUS RTU/ASCII або MODBUS+). Як приклад можна привести рис.6.27, взятий зі специфікації протоколу прикладного рівня.
Аналогічно всім мережам MODBUS, дана мережа використовує MODBUS Application Protocol. Нагадаємо, що в MODBUS Serial на канальному рівні до PDU добавляється адреса веденого і контрольна сума, сам PDU не модифікується. Однак в MODBUS TCP/IP перед попаданням на транспортний рівень, до PDU (код функції та дані) додається додатковий MBAP-заголовок. (рис.6.28). Заголовок складається з полів, які описані в табл.6.6. Отриманий модуль передається рівню ТСР.
 

Зверніть увагу, що за допомогою поля UnitID можна вказати адресу вузла в MODBUS Serial, наприклад адресу Веденого в MODBUS RTU. Якщо потрібно адресувати вузол, безпосередньо підключений по TCP/IP то  UnitID=0.

Поле ProtocolID використовується для міжсистемного мультиплексування. Так ТСР порт для MODBUS серверу має номер 502, однак цей же порт, наприклад, використовує Schneider Electric для UNITE-Серверу. Таким чином замінивши поле  ProtocolID Ethernet модулі ПЛК Schneider Electric одночасно підтримують два протоколи: MODBUS та UNI-TE.

 

Таблиця 6.6

Поля MBAP заголовка

Поле

Дов-жина (байт)

Пояснення

Клієнт

Сервер

TransactionID

2

ідентифікація транзакцій запитів/ відповідей

ініціалізує Клієнт в запиті

копіює з запиту у повідомлення -відповідь

ProtocolID

2

тип протоколу, 0=MODBUS протокол

ініціалізує Клієнт в запиті

копіює з запиту у повідомлення -відповідь

Length

2

кількість наступних байтів

ініціалізує Клієнт в запиті

ініціалізує Сервер у відповіді

UnitID

1

адреса Веденого, який підключений до вузла

ініціалізує Клієнт в запиті

копіює з запиту у повідомлення -відповідь

 

Для ідентифікації пристрою, якому передається запит, вказується його IP-адреса. Для ідентифікації TPDU, які направляються MODBUS-Серверу, як прикладному об’єкту, виділений 502-гий TCP-порт. З деталями функціонування стеку TCP/IP а також Ethernet можна ознайомитись в літературі по комп’ютерним мережам а також в розділі 10. Крім того там наведені деякі пояснення з приводу обмежень використання рішень подібних MODBUS TCP/IP, зокрема в системах з жорсткими вимогами до реального часу.

Приклад 6.7. MODBUS. Реалізація MODBUS TCP/IP Клієнтської програми для зв’язку VIPA Speed7 з віддаленими модулями вводу/виводу VIPA IM 253NET.

Завдання. Написати прикладну програму в середовищі Step7 для реалізації періодичного (1 раз в 500мс) зчитування значення 4-х аналогових входів в ПЛК Vipa Speed7NET з віддалених модулів вводу/виводу на базі VIPA IM 253NET (рис.6.29) .

Рішення. Даний приклад розглянутий з максимальними спрощеннями і без деталізації, яка не стосуються даної теми. Враховуючи, що для програмування VIPA можна скористатися іншим програмним продуктом (WinPLC7) деталі створення конфігурації для Step7 в прикладі упущені. Слід також відмітити, що Siemens пропонує свій комунікаційний функціональний блок, як для реалізації Клієнта так і Сервера MODBUS TCP/IP, однак в даному прикладі використовуються стандартні функції AG_SEND та AG_RECV.

З рис.6.29 видно, що 4-ри 12-бітні входи будуть зчитуватися як 4 слова. Оскільки вони знаходяться на першому посадочному місці, змінна AI0 – буде адресуватись як 0-вий вхідний регістр, а AI3 – як 3-тій. Таким чином задачу можна сформувати так: написати прикладну програму в ПЛК Vipa Speed7NET (IP=192.168.0.1) для реалізації зчитування по MODBUS TCP/IP перших 4-х вхідних регістрів з Серверу з адресою IP=192.168.0.2. При такій постановці вже не важлива конкретика реалізації віддаленого пристрою.

Для повноти картини наведемо схему мережних з’єднань (рис. 6.30). Слід відмітити, що у VIPA S7 NET серед 2-х портів Ethernet X8 та X5 тільки один порт, а саме X8(TP), може використовуватись для різних типів з’єднань аналогічних CP343 від Siemens. Інший порт (X5) може використовуватись тільки для PG/OP з’єднань. Таким чином, для з’єднання даного ПЛК по MODBUS TCP/IP необхідно використати роз’єм Х8 (ТР).

Для реалізації обміну по протоколу TCP в S7-подібних контролерах конфігурують з’єднувальні канали (Connections). Для кожного каналу вказують:

-         локальний процесор, для якого конфігурується канал;

-         точку виходу в мережу, тобто комунікаційний модуль;

-         ідентифікатор з’єднання;

-         активність з’єднання, тобто чи ініціює даний вузол з’єднання;

-         адреса комунікаційного партнеру, з яким настроюється з’єднання (IP та TCP port);

-         локальний  TCP port для з’єднання.

В принципі, використовуючи з’єднувальні канали, можна обмінюватися поверх TCP по будь-якому відкритому протоколу. Тому MODBUS TCP/IP є один із багатьох варіантів використання даного типу комунікацій Siemens. Так, наприклад, Step5 сумісний зв’язок теж конфігурується подібним чином, однак порти TCP будуть інші і протокол прикладного рівня теж інший.

Для поставленої задачі створюється з’єднувальний канал з наступними характеристиками:

-         канал створюється на стороні процесору VIPA S7 NET;

-         точка виходу в мережу (маршрутизатор) – вибираємо порт ТР (віртуальний модуль CP343), після чого в конфігураторі отримується адреса даного модуля відповідно до його розміщення в корзині (=14016) ;

-         тип каналу =TCP;

-         ідентифікатор з’єднувального каналу вибираємо довільний, наприклад  3 ;

-         з’єднання активне з цього боку, чим вказуємо, що даний вузол в з’єднанні представляє бік клієнта TCP;

-         вказуємо ІР-адресу комунікаційного партнеру, тобто IP=192.168.0.2;

-         вказуємо TCP port для партнеру, TCP=502 (MODBUS Серевер);

-         вказуємо локальний, тобто клієнтський TCP port, вибираємо довільний в дозволеному діапазоні, наприклад TCP=2001.

Після такої конфігурації, навіть без написання додаткової програми, між ПЛК та модулем віддаленого вводу/виводу створиться TCP з’єднання. Однак ніякими даними користувача вузли обмінюватися не будуть.

Для передачі даних від ПЛК VIPA S7 NET, необхідно скористуватися комунікаційною функцією AG_SEND, яка поставляється з бібліотеками для VIPA. Ця функція відправляє блок даних по створеному з’єднувальному каналу. Одним із аргументів цієї функції є вказівник на блок даних, які необхідно відправити. В нашому випадку це, по суті, MODBUS TCP/IP ADU. Найбільш зручний спосіб описати в Step7 подібну структуру та виділити для неї пам’ять – це використати блоки даних типу DB. Таким чином формуємо DB10 для створення MODBUS TCP/IP ADU, відповідно до таблиці 6.5 та синтаксису функції читання вхідних регістрів (див. п. 6.2.2). Результат формування блоку DB10 в  Step7 показаний на рис.6.31.

Перші два поля при ініціалізації блока прирівнюються нулю. Поле TransactionID можна використати для відслідковування послідовності відповідей на запити (який TransactionID в запиті, такий і у відповіді), однак це не обов’язково. ProtocolID=0, бо використовується сервер MODBUS.

Кількість наступних байт залежить від функції, в нашому випадку їх 6. Адреса Веденого=0, тому що адресат знаходиться безпосередньо на Ethernet. Функція=4, оскільки необхідно зчитати вхідні регістри, початкова адреса=0 а кількість =4 (див. рис.6.28).    

Вказівник на сформований блок даних вказується в аргументах функції AG_SEND. Частина програми, яка відповідає за відправку запитів буде мати вигляд як на рис. 6.32.

Програма написана в організаційному блоці OB1 (циклічний виклик). В першому ланцюжку (Network1) кожні 500 мс, перезапускається таймер і генерується одиничний імпульс M100.0 тривалістю в один цикл. Цей імпульс використовується для відправки даних в мережу (параметр ACT) раз в 500 мс. З цією ж періодичністю в Network2 збільшується значення 0-го слова в блоці даних DB10 (DB10.DBW0), яке вказує на ідентифікатор транзакції. Крім безпосередньо вказівника на блок з даними для відправки довжиною 12 байт (параметр SEND), в функції вказується ідентифікатор з’єднувального каналу (параметр ID=3), адреса комунікаційного модуля (LADDR=14016), та кількість байт для відправки. Контроль відправки та виклику функцій проводиться за допомогою параметрів DONE (біт виконання операції), ERROR (біт наявності помилки) та STATUS (слово статусу операції), про використання яких можна можна прочитати в довідниковій літературі.

Після запуску програми на виконання, процесор ПЛК буде записувати вказані в DB10 дані в вихідний буфер комунікаційного модулю з адресою  LADDR=14016, які відправляться цим модулем по з’єднувальному каналу TCP з ідентифікатором 3. Інтерфейсний модуль розподіленої системи вводу/виводу VIPA IM 253NET, отримавши по з’єднувальному каналу дані MODBUS TCP/IP ADU, сформує повідомлення-відповідь і відправить його по цьому ж каналу. Це повідомлення попадає у вхідний буфер комунікаційного модулю. Для того, щоб прочитати дані з вхідного буферу, використовується функція AG_RECV.

В якості одного з параметрів функції AG_RECV є вказівник на дані, куди необхідно помістити результат функції, тобто дані вхідного буферу. Аналогічно попередній частині програми, найкраще використати блок даних, наприклад DB11. Значення ініціалізації полів даного блоку не відіграє ніякої ролі, оскільки заповнюється значеннями буферу. Однак бажано задати структуру блоку, яка і показана на рис.6.33.
 
Друга частина програми, в якій реалізоване отримання необхідних значень аналогових входів, показана на рис.6.34.
 

У випадку позитивного результату виконання функції та отримання нових даних (NDR=0 та ERROR=0) записуємо значення в змінні MW200-MW206, відповідно до завдання. Слід зазначити, що даний приклад значно спрощений, зокрема в ньому не враховані випадки виникнення комунікаційних помилок. Однак він показує яким чином використовується клієнтський бік MODBUS TCP/IP в Siemens-сумісних ПЛК. Аналогічно можна прописати і серверний бік MODBUS TCP/IP, однак це набагато складніша задача.

Приклад 6.8. MODBUS. Реалізація MODBUS TCP/IP Клієнтської програми для зв’язку прикладних програм з інтегрованим VBA та ПЛК.

Завдання. Написати прикладну програму в середовищі VBA (Excel) для реалізації зчитування значення 5-ти внутрішніх регістри з ПЛК по протоколу MODBUS TCP/IP. Зчитування проводити при нажиманні кнопки.

Рішення. У VBA прописуємо наступний код, показаний на рис. 6.35.

Для реалізації даної задачі використаний ActiveX-елемент Winsock (має назву Winsock1), який як правило вже присутній на комп’ютерах з операційною системою Windows. Цей компонент являється інтерфейсом до однойменного сервісу в операційній системі Windows і функціонує  приблизно так як модель сокетів (див.розділ 10). Він може працювати як в режимі TCP так і UDP. Для останнього - з’єднання проводити не потрібно. Достатньо розмістити Winsock елемент на контейнері (наприклад формі) і можна користуватися його методами, властивостями та подіями.
 
 

6.5. Рекомендації до проектування мереж MODBUS RTU/ASCII та MODBUS TCP.

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

6.5.1. Послідовність розробки мереж MODBUS RTU/ASCII

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

-         засоби людино машинного інтерфейсу (ЛМІ), до яких відносяться ОП та комп’ютери зі SCADA/HMI;

-         контролери, яким необхідно доступатись до інших контролерів або до периферійних засобів;

-         програматори або конфігуратори.

Нагадаємо, що засоби ЛМІ обмінюються даними з контролерами, периферійними засобами або іншими засобами ЛМІ. Для відображення плинних даних процесу, засоби ЛМІ опитують їх значення з певною періодичністю тільки тоді, коли сторінка відображення є активною. Така поведінка є логічною, оскільки економляться часові ресурси мережі. Однак деякі засоби ЛМІ дають можливість постійного опитування даних. Зокрема це характерно для операцій ведення архівів а також для задач тривог та аварій. Запис даних процесу з ЛМІ проводиться як правило тільки при їх зміні. Тому логічним є те, що засоби ЛМІ в мережі повинні бути Клієнтами. Виключенням можуть бути ситуації, коли в мережі повинно бути декілька засобів ЛМІ, або коли є необхідність в передачі термінових повідомлень на термінал. Ці ситуації розглянуті нижче.

При необхідності обміну даними контролера з іншим контролером, або з периферійними засобами, він повинен ініціювати обмін, тобто бути Клієнтом.

Програматори та конфігуратори теж повинні бути Клієнтами. В зв’язку з тим, що підключення їх до мережі проводиться тільки при необхідності, та при умові відсутності вимог до одночасного функціонування мережі разом зі зміною конфігурації/програми мережних вузлів, можна вважати, що програматор не входить в структуру мережі. В іншому випадку, необхідно виділяти окремий канал, тобто виділяти окрему мережу для пристроїв, які необхідно програмувати, якщо таке можливе (блок 14).   

В будь якому випадку, кількість клієнтських вузлів не може бути більше одного, оскільки прикладний процес Клієнта в одній мережі MODBUS RTU може знаходитись тільки на Ведучому. Якщо кількість Клієнтів (блок 1) все ж таки більше одного можна спробувати перенести клієнтські запити вузлів на один вузол з правами Ведучого (блок 4). Нижче розглянуті декілька прикладів такого переносу. Якщо перенос не вдається по певним причинам необхідно на вузлах виділити окремі канали, тобто замість одної мережі створити декілька мереж, якщо таке можливо (блоки 14 та 16), або змінити забезпечення вузлів (блок 15).
 

Якщо Клієнт тільки один, його прикладний Процес буде виконуватися на вузлі з правами Ведучого шини (блок 3). Після всіх проведених вище перевірок, необхідно узгодити фізичні інтерфейси (блок 5) та при необхідності використати адаптери перетворювачі. При великих довжинах ліній необхідно підібрати репітер, після чого визначитися з кінцевою структурою, бітовим швидкостям та перевірити відповідність фізичних характеристик вимогам MODBUS RTU.

При наявності часових комунікаційних характеристик для портів всіх засобів, які приймають участь в обміні, бажано розрахувати орієнтований час обміну, розрахунок якого показаний в прикладі 6.4. Якщо час обміну задовольняє, то мережа підходить для вирішення поставлених задач і можна переходити до розробки документів робочого проекту.             

6.5.2. Перенесення клієнтських запитів в мережах MODBUS RTU/ASCII

Якщо при проектуванні мережі MODBUS RTU виявилось декілька прикладних Процесів Клієнтів, можна спробувати їх перенести на один вузол.

На рис.6.37 показаний приклад вирішення задачі, в якій необхідно поєднати в мережу чотири ПЛК (PLC1-PLC4) , для обміну даними з певною періодичністю. Розглянемо, який з PLC повинен бути Клієнтом, а отже і Ведучим MODBUS RTU.

Враховуючи, що обмін даними повинен бути періодичним, то кожен з ПЛК для інформаційних потоків може бути як ініціатором обміну, тобто Клієнтом, так і Сервером. Чи можна виділити єдиний Клієнтський вузол? PLC1  – не може бути єдиним клієнтським вузлом, бо присутній інформаційний зв’язок між PLC3 та PLC4. PLC2 теж не може, із-за зв’язків PLC3-PLC1 та PLC3-PLC4. Для PLC3 так як і для PLC4 залишається недосяжними зв’язок PLC1-PLC2. Для PLC4 крім того не може бути Клієнтом із-за зв’язку PLC3-PLC1. Таким чином явно виділяються як мінімум два Клієнти: PLC1 та PLC3.
 
 

Рішення даної задачі може бути перенесення клієнтських запитів на один із вузлів, наприклад PLC3. Прямі клієнтські запити залишаються: PLC3 записує значення змінні3_1 в змінні1_1, зчитує значення зі змінні4 в змінні3_2. Для реалізації зв’язку між змінні2 та змінні1_2, необхідно щоб PLC3 зчитував ці значення з PLC2, після чого записував їх в PLC1. Як правило для цього виділяється додатковий буфер, в прикладі це змінні3_3.       

Вибір вузла з клієнтським прикладним Процесом, а отже Ведучого, може проводитись по різними критеріями: здатність комунікаційних каналів працювати в режимі MODBUS RTU Ведучого або Веденого, потужність комунікаційних каналів (продуктивність запитів що може обробити ПЛК), потужність процесору, зручність програмування або конфігурування, кількість прямих клієнтських запитів, зручність налагоджування, тощо. В нашому випадку ми зупинилися на PLC3, що обумовлено зменшенням кількості непрямих клієнтських запитів.  

Розглянемо наступний випадок. При необхідності підключення до єдиної мережі MODBUS RTU декількох засобів людино-машинного інтерфейсу, які, як ми зазначили, повинні формувати клієнтські запити, виникає необхідність в декількох Ведучих. На рис.6.38 продемонстрований приклад, в якому необхідно підключити дві операторські панелі до одного ПЛК як для відображення так і для управління. Жодна з операторських панелей не може взяти на себе ексклюзивні права Клієнта, оскільки інша операторська панель не зможе отримувати дані. Якщо операторські панелі підтримують MODBUS RTU в режимі Веденого, а ПЛК в режимі Ведучого, то рішення цієї задачі може бути як на рис.6.38 (зправа). Для цього в операторських панелях повинна бути виділена область пам’яті (на рис.6.38 змінні2 та змінні3), з якою буде обмінюватись ПЛК, генеруючи запити на читання та запис регістрів/бітів. Відображення та зміна значень змінні1 з операторських панелей буде проходити через ці виділені області.
 

Хоч в розглянутому прикладі використовуються операторські панелі, аналогічно вирішується ситуація, коли в якості засобів людино-машинного інтерфейсу виступають ПК зі SCADA, або комбінація ОП та SCADA. Для SCADA в цьому випадку необхідна наявність драйверів MODBUS RTU в режимі Веденого.

В даній задачі можливе перенесення клієнтських запитів на один із засобів людино-машинного інтерфейсу. Однак це далеко не завжди можливо, оскільки в цьому випадку необхідно реалізувати переприсвоєння змінних з різними джерелами даних. Крім того, засоби ЛМІ в більшості випадків не можуть забезпечити детермінований час доставки даних.

6.5.3. Послідовність розробки мереж MODBUS TCP/IP

На відміну від MODBUS RTU/ASCII в MODBUS TCP/IP, що як правило базується на Ethernet, немає проблем з наявністю клієнтських запитів тільки на одному вузлі. Прикладний Процес на вузлі може одночасно бути як Клієнтом так і Сервером. При розробці мережі враховують фізичні особливості засобів Ethernet (див. розділ 10). Таким чином в загальній послідовності проекту мережі можна виділити такі кроки:

1.     Визначення клієнтських вузлів.

2.     Визначення підтримки потенційними клієнтськими вузлами режиму MODBUS Клієнта, а серверних – режиму MODBUS Серверу.

3.     Перенесення клієнтських або серверних запитів на інші вузли при необхідності.

4.     Розрахунок орієнтовного часу транзакції між вузлами Клієнта та Сервера.

5.     Розробка мережних схем на базі Ethernet.

Розрахунок орієнтованого часу транзакції для MODBUS TCP/IP базується на тих саме принципах що і MODBUS RTU/ASCII. Однак замість часу, який витрачається на передачу кадру, необхідно врахувати час реакції комунікаційних засобів Etherent (концентраторів, комутаторів, мостів, шлюзів і т.д.).

         

 

Контрольні запитання до розділу 6

 

1.     Якими мережами на сьогоднішній день представлений MODBUS? Охарактеризуйте їх в контексті моделі OSI.

2.     Розкажіть про основи функціонування MODBUS Application Protocol. Який формат повідомлення MODBUS PDU? Як поділяються коди функцій з точки зору MODBUS-IDA?

3.     Як MODBUS-серверний Процес дізнається про помилковий результат обробки повідомлення-запиту?

4.     Які функції використовуються для доступу до даних процесу?

5.     Як формуються повідомлення-запити та повідомлення відповіді для читання та запису діапазону вхідних та вихідних регістрів?

6.     Які ситуації можливі при обробці запиту MODBUS Клієнта? Наведіть приклади відповідей про помилку.

7.     Що таке MODBUS відображення даних? Які моделі відображення даних MODBUS використовуються в сучасних засобах автоматизації?

8.     Прокоментуйте основи функціонування MODBUS RTU/ASCII в контексті моделі OSI. Як пов’язана модель функціонування обміну на прикладному рівні з функціонуванням на канальному?

9.     Яка модель адресації та який метод доступу до шини використовується в MODBUS RTU/ASCII на канальному рівні? Як на цьому рівні проводиться контроль за правильністю доставки бітової послідовності?

10. В чому відмінність роботи MODBUS RTU та MODBUS ASCII на канальному та фізичному рівні?

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

12. Розкажіть про принципи побудови кадрів для  MODBUS RTU та MODBUS ASCII.

13. Які інтерфейси, бітова швидкість та топологія використовується для  MODBUS RTU/ASCII на фізичному рівні? Яким чином вузли можуть підключатися до загальної шини?

14. Як реалізовується двохпроводне з’єднання вузлів по MODBUS RTU/ASCII? В якому місті і як реалізовується захисне зміщення?

15. Які типи роз’ємів визначені в стандартах MODBUS-IDA для підключення пристроїв до шини по RS-485?

16. Які основні недоліки ви можете назвати в принципах функціонування мереж MODBUS RTU/ASCII?

17. Прокоментуйте основи функціонування MODBUS TCP/IP в контексті моделі OSI. Які типи пристроїв передбачає комунікаційна архітектура MODBUS TCP/IP?

18. Які поля включає формат модуля даних прикладного рівня MODBUS TCP/IP? Поясніть призначення полів заголовка MBAP?

19. Яка адреса порту ТСР використовується для MODBUS Сервера?

20. Яким чином забезпечується доступ до необхідного вузла MODBUS RTU/ASCII, підключених через шлюз до MODBUS TCP/IP в заголовку MBAP?

21. Які вузли як правило являються ініціаторами обміну в MODBUS RTU/ASCII? Поясніть чому?

22. Навіщо необхідно визначати вузли з клієнтськими запитами? Чому вузол з клієнтським Процесом в MODBUS RTU/ASCII може бути тільки один?

23. Наведіть приклади переносу клієнтських запитів на один вузол. Які обмеження при цьому є?

В чому відмінність проектування MODBUS TCP/IP порівняно з MODBUS RTU/ASCII?
 
 
 Оставить комментарии Вы можете здесь http://pupena-san.blogspot.com
 
 
 
 
 
 
Comments