hu:comm:bus_modbus

Modbus logo

MODBUS

en: Modicon bus busz modbus A Modbus protokoll kialakulása szorosan összefonódott az első PLC születésével. Az első PLC, a"Modicon 084" 1969-ben kezdte meg első ciklusait, és rá egy évre, szükségszerűen létrehozták a Modbus-t. Az eredeti Modbus (eddigi ismereteim szerint) egy meglehetősen elbonyolított, de nyílt protokoll volt. Az eltelt több évtized azt bizonyítja, hogy a Modbus-t azért rendesen eltalálták a szerzői, bár, ez a protokoll már nem az, az 1970-es (más források szerint 1979-es) cucc.
Ezt jellemzően finoman úgy lehet megfogalmazni, hogy ez egy De-facto-standard, azaz, igen széles körben alkalmazott kommunikációs rendszer, amit ellenben mindenki úgy használ, ahogy akar. Vannak ugyan kötött szabályai, de a legtöbb gyártó ezeket meglehetősen tágan értelmezi.

Ezáltal, ha két Modbus-osnak definiált, de nem egy gyártótól származó eszközt kíván összekötni, a dolgot még véletlenül se bagatellizálja el, és a kommunikáció kipróbálása nélkül ne adjon rá árajánlatot (a fájdalmas tapasztalatok beszélnek belőlem).

A Modbus egy olyan protokoll, mint a világ háta mögötti, ember még soha nem járta madártelepek szigetei. A guano évről-évre rakódik le rajtuk, egyszerű rétegződéssel.

Próbáljuk meg első körben valahogy az OSI modellbe bepasszírozni ezt a protokollt. (A neten eddig ahány besorolás - annyiféle besorolás felállással találkoztam.).

OSI-szintModbus TCPModbus RTU / ASCIITCP/IP-szint
7 Alkalmazási
réteg
(Application)
Modbus Application Protokoll (MBAP) alkalmazási réteg
(application layer)
4
6 Megjelenítési
réteg
(Presentation)
5 Viszonylati réteg
(Session)
4 Forgalmazási
réteg
(Transport)
TCP  forgalmazási réteg
(transport layer)
3
3 Hálózati
Réteg
(Network)
IPv4
IPv6
 Internet réteg
(Internet layer)
2
2 Adatkapcsolati
réteg
(Data Link)
LLC/MAC RTU (binary encoding) RTU (binary encoding)
ASCII (ASCII encoding)
adatkapcsolati réteg
(host to network layer)
1
1 Fizikai
réteg
(Physical)
IEEE 802.3 Ethernet
10Base2
10Base-T
100Base-TX
1000Base-TX
száloptika
RS232 (V.24),
RS485

A klasszikus Modbus jellemzően a már jól megszokott RS-ek nyakába ül, sokat nem bajlódik a fizikai réteg definíciójával. A Modbus voltaképpen csak a legfelső - alkalmazási réteget definiálja, ez a MBAP (MODBUS Application Protocol). Ez - elvileg - minden esetben egységes, de persze tudjuk, hogy a gyakorlat szinte mindig mást mutat.

A TCP/IP világa sok változást nem hozott a protokollban, így a megszokott MBAP itt a TCP-re települt.

A fejezet további részében a három, „alap” Modbus protokoll és ezek háttere kerül ismertetésre:

  • Modbus ASCII
  • Modbus RTU
  • Modbus TCP

Modbus communication

A Modbus egy monomaster hálózatot vagy pont-pont kapcsolatot feltételez. Mindkét esetben egy master és legalább egy slave szükséges a kommunikációhoz. A Modbus RTU csak egy master egység jelenlétét teszi lehetővé.

A Modbus hálózaton egyszerre több master is jelen lehet (multimaster), de ez esetben ún. multimaster-gateway-t kell beiktatnunk a kummunikációs hálózatba, és a masterek csak Modbus TCP-re lehetnek felfűzve:

Modbus Multimaster

RTU/ASCII: A slave-ek száma nem haladhatja meg a 246-ot, címzésük az 1..247-es tartományban történhet. A gyakorlat szerint egy szegmensben 32 állomás lehet, és csak repeater-ekkel bővíthető a hálózat. A 0. címmel broadcast üzeneteket lehet küldeni, amennyiben ez a művelet logikai szinten nincs korlátozva. A master jellemzően az 1. címet szokta megkapni.

 A TCP esetén az RTU-t telepítették a TCP-re, így az ethernetes hálózatok összes előnyét sikerült beágyazni a Modbusba. Mivel az etherneten az állomások címe nagyságrendekkel magasabb, mint az RTU/ASCII-nél, így ennek a korlátját a Modbus-ban definiált 1 bájtos címe jelenti (itt is marad az 1..247 korlát).

elsődleges táblákobjekt típusaírás/olvasásleírás
Discretes Input
(egyedi input)
Single bitRead-Onlyez a típus az I/O rendszer általi eléréshez használható
Coils
(talán tekercsek?)
Single bitRead-Writeennek a típusnak az adatai applikációs programmal kezelhetők - változtathatók
Input Registers
(input regiszterek)
16-bit wordRead-Onlyez a típus az I/O rendszer általi eléréshez használható
Holding Registers
(megfogott regiszterek)
16-bit wordRead-Writeennek a típusnak az adatai applikációs programmal kezelhetők - változtathatók

A fenti táblázat egy - 1979-es, igazán útkereső kommunikációs koncepció világlátását tükrözi, az elnevezésekben. A lényeg az objektum típusa oszlopból és az írás / olvasás tulajdonságból jön le. Van bites és szavas elérés, és van csak olvasás és írás/olvasás lehetőség. Ennyi.

en: Modbus Application Protokoll

Az MBAP voltaképpen maga a Modbus protokoll. Az OSI-Modell meghatározása szerint ez az Alkalmazási réteg szintjén található, csakhogy a Modbus voltaképpen nem is nagyon áll másból. A rend kedvéért az ASCII / RTU encoding-ot felpakolták az adatkapcsolati rétegbe, de a protokoll többi megvalósítását az RS-ek és a TCP vállalják át.

A telegramok a (klasszikus) ASCII / RTU esetében a lenti ábrán látható tagolásban kerülnek továbbításra. A TCP esetében a PDU-n kívül eső részek kezelését a TCP protokoll veszi át, így ott már csak a PDU marad meg.

Modbus ADU/PDU

A klasszikus Modbus a telegramokban két szerkezeti tagolást különböztet meg:

ADU : Applikációs adategység

en: Application Data Unit

Applikációs szempontból magába foglalja az összes adatrészt, így a címet és a CFC-t vagy LFC-t is.

PDU: Protokoll adategység

en: Protocol Data Unit

Csak a funkciókódot és az adatot foglalja magába. A PDU az átviteli protokolltól független rész, melyet az MBAP generál az alkalmazási réteg szintjén. Lásd OSI modell.

Abból a tényből következően, hogy a PDU-beli címzésre 2 bájt áll rendelkezésre, a tárterületek címzésének a felső határa 65536.

PDU-k felépítése

A Modbus kommunikáció kérdés - válasz típusú kommunikációra épül.  A telegramok tartalmuk szerint az alábbi három csoportba oszthatók:

PDU típusaleírása
kérdés
(request : kérés, kérelem)
Minden esetben tartalmazza a funkciókódot, majd jellemzően utalás található benne a kezdőcímre és a lekérdezés hosszára.
válasz
(response: felelet, válasz)
A funkciókód megegyezik a kérdés funkciókódjával, ha a művelet a megszólított fél oldalán probléma nélkül végrehajtható. Jellemzően megadja a válasz hosszát és tartalmát.
hiba
(error)
Ha a megszólított fél oldalán hiba merül fel, ezzel a tartalommal válaszol a kérdésre. A funkciókód mezőben a funkciókód + 0x80 választ ad, és az adatmezőben a probláma okát próbálja felfedni. Ez az un. exception code, ennek értéke 01, 02, 03 vagy 04 lehet.

A PDU-k kiértékelése a fogadó oldalon az alábbi folyamatábra szerint zajlik:

Modbus PDU check (flow chart) 

kódmegnevezésjelentése
01ILLEGAL FUNCTIONAz elküldött telegram funkciókódja szerinti művelet az adott állomáson nem hajtható végre. Legtöbb esetben például olyan kód megy el a célállomásra, ami csak az újabb (vagy csak a régebbi) egységeken hajtható végre. Eltérő konfigurálás miatt is előfordulhat az elutasítás.
02ILLEGAL DATA ADDRESSAz adott egységen a megadott címtartományban a művelet nem hajtható végre. Jellemzően ebben az esetben címtartományból kicímzések esetén fordul elő ez a hiba. Ha a rendelkezésre álló regiszterek száma például 50, és a 46.-tól címzünk 5 regisztert, előcsalhatjuk a hibát.
03ILLEGAL DATA VALUEA kérdés telegramban szerepelő adat pontatlan, a célállomás számára nem értelmezhető.
04SLAVE DEVICE FAILUREA célállomás - visszaállíthatatlan hibára hivatkozva - elutasítja a művelet végrehajtását.
05ACKNOWLEDGEJellemően parancsvégrehajtás esetén szokott felbukkanni.
A célállomás fogadta a telegramot és a végrehajtását is megkezdte, de jellemzően időtúllépés miatt elküld egy ilyen tartalmú telegramot. A célállomás a művelet lezártával küld(het) egy „Poll Program Complete” üzenetet.
06SLAVE DEVICE BUSYJellemzően parancsvégrehajtás esetén szokott felbukkanni.
A célállomás jelzi a hívó félnek, hogy folyamatban levő végrehajtás miatt nem tud új telegramot fogadni. A telegram küldését a későbbiekben ismételni kell ennek a válasznak az esetén.
08MEMORY PARITY ERRORA művelet végrehajtása közben a célállomás belefutott egy memória paritáshibába, és ezt muszáj közölnie a hívó féllel.
0AGATEWAY PATH UNAVAILABLEJellemzően azokban az esetekben lép fel, ha az okos rendszergazda elkonfigurálja a gatway-t, vagy egyszerűen túlterhelt az.
0BGATEWAY TARGET DEVICE FAILED TO RESPONDAz adott állomás lehullott a hálózatról, ezért nem érhető el.

Modbus funkciós kódok cím szerinti felosztása

Modbus functionscodes sequences

Modbus funkciós kódok csoportosítása

kód csoportosításakód leírásakódal-kód
data access

adatelérés
bit access

bites elérés
Physical Discrete Inputs

egyedi fizikai címek
read discrete inputs
egyedi inputok olvasása
02
 
Internal Bits Or Physical coils

belső bit vagy fizikai coil
read coils
coil-ek olvasása
01  
Write Single Coil
egyedi coil írása
05  
Write Multiple Coils
többszörös coil írás
15  
16 bits access

szavas elérés
Physical Input Registers

Internal Registers
Or
Physical Output Registers

fizikai input regiszter

belső regiszter
vagy
fizikai kimeneti regiszter
Read Input Register
input regiszter olvasása
04  
Read Holding Registers
megfogott regiszterek olvasása
03  
Write Single Register
egyedi regiszter írása
06  
Write Multiple Registers
többszörös regiszterek írása
16  
Read/Write Multiple Registers
többszörös regiszter írás / olvasás
23  
Mask Write Register
maszkolt regiszter írás
22  
Read FIFO queue
FIFO lekérdezés
24  
File record access

fájlrekord elérés
Read File record
fájlrekord olvasása
20  
Write File record
fájlrekord írása
21  
Diagnostics

diagnosztika
Read Exception status
hibakód olvasása
07  
Diagnostic
diagnosztika
08 00 - 18, 20
Get Com event counter 11  
Get Com Event Log 12  
Report Slave ID 17  
Read device Identification 43 14
Other

egyéb
Encapsulated Interface Transport 43 13, 14
CANopen General Reference 43 13

Azért ezt a dokumentumot lusta vagyok lefordítani (meg minek is). Tehát ezek leírása itt található: Modbus_Application_Protocol_V1_1b (pdf)

A Read Coil (0x01) eljárással szeretnénk kiolvasni a 19 - 37 output mezők tartalmát.

Request (lekérés)

PDUPDU tartalmamező hosszaértéke vagy
határértéke
példa
funkciókódfunkciókód1 bájt0x010x01
adatkezdőcím2 bájt0x0000 - 0xFFFF0x00 (HI) 0x12 (LO)
coil darabszáma2 bájt1 - 2000 (0x7D0)0x00 (HI) 0x13 (LO)

Response (válasz)

PDUPDU tartalmamező hosszaértéke vagy
határértéke
példa
funkciókódfunkciókód1 bájt0x010x01
adatbájok száma1 bájtn0x03
coil-ok státusza
(bájtokban)
n bájtn = n vagy n+10xAB
0xCD
0xEF

Error (hiba)

PDUPDU tartalmamező hosszaértéke vagy
határértéke
példa
funkciókódfunkciókód1 bájtfunkciókód + 0x800x81
adatException code1 bájt01, 02, 03 vagy 040x01
 Modbus / ASCIIModbus / RTU
Karakterek ASCII 09 és A..F Bináris 0255
Hibaellenőrzés LRC (Longitudinal Redundancy Check) CRC (Cyclic Redundancy Check)
Keret kezdet kettőspont karakter ':' 3.5 karakternyi szünet
Keret vég sor vége / új sor karakterek CR/LF 3.5 karakternyi szünet
Gap-ok az üzenetben 1 sec 1.5 karakter
Start bit 11
Adat bitek 78
Paritás even / oddnoneeven / oddnone
Stop bitek 1212

A paritásról, start és stop bitekről bővebben az RS232 fejezetben olvashat.

Az átvitel sebessége (meg az összes egyéb jellemzője) az alkalmazott RS technikától függ, ezek összevetését itt találja meg.

A telegramok felépítése az ASCII/RTU esetén - néhány kisebb eltéréstől eltekintve - alapvetően azonos.

Mező neveADU / PDULeírás
Start-of-frame (SOF)-Az adatátvitel megkezdését jelző bájt vagy bájtsorozat.
címADU0: broadcast, 1..247: állomáscím
funkciókódADU/PDUezeknek leírását a funkciókód fejezetben találja meg. Eredetileg ezek egységes rendszert képeznek.
0: érvénytelen funkciókód
1..127: szabadon használható funkciókódok
128..255: fenntartott funkciókódok
adatokADU/PDUa funkciókód által meghatározott adatok. Az adatmező hosszát is a funkciókód határozza meg.
LR/CR ellenőrzésADUA telegram tartalmának ellenőrzőkódja.

en: American Standard Code for Information Interchange

A protokoll ASCII formában viszi át az információt, így előnye, hogy terminálon keresztül az átvitt adatsor egyszerűen olvasható, hátránya (az RTU-hoz képest) hogy kevésbé hatékony.

SOFcímfunkciókódadatokLR-ellenőrzésstop
kettőspont karakter (:)2 karakter2 karaktern karakter2 karakter2 karakter (CRLF)

en: Remote Terminal Unit, de: entfernte Terminaleinheit

A protokoll az információkat bineáris formában továbbítja, így hatékonyabb átviteli forma, mint az ASCII. A Modbus TCP ennek az átvitelnek a TCP-re adoptált változata.

SOFcímfunkciókódadatokCR-ellenőrzésstop
Várakozási idő
(min. 3,5 karakter)
8 bit8 bitn*8 bit16 bitVárakozási idő
(min. 1,5 karakter)

A Modbus TCP a fent már leírt Modbus RTU TCP-re ültetett változata, mely értelemszerűen ethernetet használ az átvitelhez és a TCP/IP keretezési követelményeinek felel meg. Az állomások száma nincs korlátozva, az átvitel sebességét a kiépített hálózat határozza meg.

tranzakció-számprotokoll-kódátvitelre kerülő bájtok számacímfunkciókódadatok
2 byte2 byte
(mindig 0x0000)
2 byte (n+2)1 byte1 byten byte
  • hu/comm/bus_modbus.txt
  • 2022/04/21 15:03
  • ()