Modbus

Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2020. március 17-én felülvizsgált verziótól ; az ellenőrzések 44 szerkesztést igényelnek .

A Modbus  egy nyílt kommunikációs protokoll , amely a master-slave architektúrán alapul ( angolul master  -slave ; a Modbus szabványban a kliens-szerver kifejezéseket használják ). Az iparban széles körben használják elektronikus eszközök közötti kommunikáció megszervezésére . Használható adatátvitelre soros kommunikációs vonalakon RS-485 , RS-422 , RS-232 és TCP/IP (Modbus TCP) hálózatokon. Vannak nem szabványos UDP -t használó implementációk is [1] [2] .

Ne keverje össze a "Modbus" és a "Modbus Plus" kifejezéseket. A Modbus Plus a Schneider Electric tulajdonában lévő szabadalmaztatott protokoll . A Modbus Plus fizikai rétege egyedülálló, hasonló az Ethernet 10BASE-T- hez , félduplex egy csavart érpáron , sebessége 2 Mbps. A Modbus Plus szállítási protokoll a HDLC , amelyen a Modbus PDU átvitel kiterjesztése van megadva.

A JBUS a Modbus RTU protokoll egy részhalmaza, kis eltérésekkel a címzési módszerben [3] .

Történelem

A Modbus-t a Modicon (jelenleg a Schneider Electric tulajdona ) fejlesztette ki programozható logikai vezérlőiben való használatra . A protokoll specifikációt először 1979-ben tették közzé [4] . Ez egy nyílt szabvány volt, amely leírta az üzenetek formátumát és azt, hogy hogyan továbbították őket különféle elektronikus eszközök hálózatán.

Kezdetben a MODICON vezérlők az RS-232 [4] soros interfészt használták . Később az RS-485 interfészt kezdték használni, mivel nagyobb megbízhatóságot biztosít, lehetővé teszi hosszabb kommunikációs vonalak használatát és több eszköz csatlakoztatását egy vonalhoz.

Számos elektronikai berendezés gyártója támogatta a szabványt, több száz ezt használó termék jelent meg a piacon.

Modbus szabvány

A Modbus fejlesztését jelenleg a Modbus-IDA [5] non-profit szervezet végzi .

Specifikus terminológia

• A PDU ( Protocol Data Unit ) a Modbus csomag része, amely minden fizikai szinten közös. Tartalmazza a funkciókódot és a csomagadatokat.
• Az ADU ( Application Data Unit ) egy teljes Modbus csomag. Tartalmazza a csomag és a PDU fizikai rétegspecifikus részét.

A Modbus 4 adattípust határoz meg:

• A Discrete Inputs  egy bites, csak olvasható típus.
• A tekercsek  egybites típusúak, olvashatók és írhatók.
• Bemeneti regiszterek  – 16 bites aláírt vagy előjel nélküli típus, csak olvasható.
• Holding Registers  – 16 bites aláírt vagy előjel nélküli típus, olvasható és írható.

A szabvány összetétele

A Modbus szabványok 3 részből állnak:

• A Modbus Application Protocol dokumentum tartalmazza az OSI hálózati modell alkalmazási rétegének specifikációját :
  • Egy elemi protokollcsomag, az úgynevezett PDU ( Protocol Data Unit ), minden fizikai rétegben ugyanaz. A PDU egy szállítás-specifikus alkalmazásadat-egységbe ( ADU ) van csomagolva.
  • Funkciókódok és PDU-tartalom minden kódhoz.
• A Modbus over serial line dokumentum tartalmazza az OSI hálózati modell kapcsolati és fizikai rétegeinek specifikációját az RS-485 és RS-232 fizikai rétegekhez. Elvileg bármely aszinkron adó -vevőn alapuló fizikai réteg használható .
• A Modbus Messaging on TCP/IP Implementation Guide (Modbus Messaging on TCP/IP Implementation Guide) dokumentum tartalmazza a TCP/IP-veremen keresztüli szállításra vonatkozó ADU specifikációt.

A szabvány előnyei

A szabvány fő előnyei a nyitottság és a tömegjelleg. Az ipar jelenleg (2014) számos típusú és modellt gyárt érzékelőkből, aktuátorokból, jelfeldolgozó és normalizáló modulokból stb. Szinte minden ipari felügyeleti és vezérlőrendszer rendelkezik szoftver-illesztőprogramokkal a Modbus hálózatokkal való együttműködéshez.

A szabvány hátrányai

A szabványt alapvetően 1979-ben dolgozták ki, figyelembe véve az akkori igényeket és számítási lehetőségeket, és számos, a modern ipari hálózatok szempontjából lényeges kérdést nem vettek figyelembe [6] . Ezen jellemzők hiánya a protokoll egyszerűségének a következménye, ami megkönnyíti a tanulmányozását és felgyorsítja a megvalósítást.

• A szabvány csak kétféle adat átvitelére határoz meg módszert [7] . A szabványban szereplő egyértelmű jelzés hiánya oda vezetett, hogy a Modbus megoldások külső gyártói saját belátásuk szerint jártak el más típusú adatokkal. A berendezésgyártók véleménykülönbsége ebben a kérdésben nem tette lehetővé a hivatalos dokumentum utólagos pontosítását: ez elégedetlenséget okozna a szabvány javasolt módosításaival nem értő gyártók körében, és egy esetleges formátumháborút okozna.
• A szabvány nem szabályozza a rendszer kezdeti inicializálását . A hálózati címek hozzárendelése és az egyes eszközök paramétereinek regisztrálása a rendszerben manuálisan történik a rendszer adaptációjának és programozásának szakaszában.
• Nem rendelkezik a slave eszköz által kezdeményezett üzenetek továbbításáról (megszakítások) [7] . A masternek rendszeresen le kell kérdeznie a slave-eket.
• Az igénylés időtartama korlátozott, adatok csak egymást követő nyilvántartásokból kérhetők le. Ez növeli a késleltetést és a többletterhelést a hálózat használatakor, hiszen ahhoz, hogy a címtérben egymástól távol elhelyezkedő regiszterekből adatokat kapjon, a masternek vagy szükségtelen adatokat kell kérnie, vagy többszörös kérést kell alkalmaznia [7] .
• Nincs mód arra, hogy a slave észlelje a kommunikáció megszakadását a masterrel [7] .

Bevezetés

A Modbus buszon lévő vezérlők egy kérésből és válaszból álló tranzakciókon alapuló master-slave modell segítségével kommunikálnak.

Általában csak egy master ( a régi terminológia szerint master ) eszköz van a hálózatban, és több slave ( a régi terminológia szerint slave szerver ) eszköz .  A mester tranzakciókat kezdeményez (kéréseket küld). A master egyenként címezheti a kérést bármelyik slave-nek, vagy üzenetszórási üzenetet kezdeményezhet az összes slave számára. A slave eszköz, miután felismerte a címét, válaszol egy kifejezetten neki címzett kérésre. Ha üzenetszórási kérelem érkezik, a slave eszközök nem generálnak választ.  

A Modbus specifikáció leírja a kérések és válaszok szerkezetét. Alapjuk egy elemi protokollcsomag, az úgynevezett PDU ( Protocol Data Unit ). A PDU felépítése független a kapcsolat típusától, és egy funkciókódot és egy adatmezőt tartalmaz. A funkciókód egybájtos mezőként van kódolva, és 1…127 tartományban vehet fel értékeket. A 128…255 értéktartomány a hibakódok számára van fenntartva. Az adatmező változó hosszúságú lehet. A PDU-csomag mérete 253 bájtra korlátozott.

Modbus PDU

funkció kódja	adat
1 bájt	N ≤ 252 (byte)

Egy csomag fizikai kommunikációs vonalakon való továbbításához a PDU-t egy másik, további mezőket tartalmazó csomagba kell helyezni. Ezt a csomagot ADU-nak ( Application Data Unit ) hívják. Az ADU formátuma a hivatkozás típusától függ. Az ADU-nak három változata létezik, kettő adatátvitelre aszinkron interfészen , egy pedig TCP/IP hálózaton keresztül:

• Modbus ASCII - csak ASCII karakterek használhatók a cseréhez. Az integritás ellenőrzésére egyetlen bájtos ellenőrző összeget használnak . Az üzenet eleje és vége speciális karakterekkel van jelölve (az üzenet eleje ":", az üzenet vége pedig CR/LF ).
• A Modbus RTU egy kompakt bináris opció. Az üzeneteket szünet választja el a sorban. Az üzenetnek legalább 3,5 karakteres némítási időközzel kell kezdődnie és végződnie adott adatátviteli sebesség mellett. Az üzenet továbbítása során ne legyen 1,5 karakternél hosszabb szünet. 19200 baud feletti sebességeknél 1,75, illetve 0,75 ms-os intervallumok megengedettek. Az integritás ellenőrzése CRC segítségével történik .
• Modbus TCP - adatátvitelhez TCP/IP kapcsolaton keresztül.

Az ADU általános felépítése a következő (a megvalósítástól függően előfordulhat, hogy néhány mező hiányzik):

a szolga (szolga) eszköz címe	funkció kódja	adat	hibaérzékelő blokk

ahol

• slave eszköz  címe — a szolga eszköz címe, amelyhez a kérés címzett. A rabszolgák csak a nekik címzett kérésekre válaszolnak. A válasz szintén a válaszoló slave címével kezdődik, amely 1-től 247-ig terjedhet. A 0-s címet a sugárzásra használják, és minden eszköz felismeri, a 248…255 tartományban lévő címek le vannak foglalva;
• a függvénykód  a keret következő egybájtos mezője. Megmondja a slave-nek, hogy a mester milyen adatokat vagy műveletet kér tőle;
• adatok  - a mező a szolga eszköznek a master által meghatározott funkció végrehajtásához szükséges információkat tartalmazza, vagy a szolga eszköz által a master kérésére továbbított adatokat tartalmazza. A mező hossza és formátuma függ a függvény számától, az adatmező tartalmazhatja a funkciókód részletét is;
• hibaészlelési blokk  - ellenőrző összeg a keretben lévő hibák hiányának ellenőrzésére.

Az ADU maximális mérete RS232/RS485 soros hálózatoknál 256 bájt, TCP hálózatoknál 260 bájt.

A Modbus TCP ADU esetében így néz ki:

Tranzakció azonosítója	Protokollazonosító	csomag hossza	rabszolga cím	funkció kódja	adat

ahol

• Tranzakcióazonosító  – két bájt, általában nullák
• Protokollazonosító  – két bájt, nullák
• csomag hossza  - két bájt, magas, majd alacsony, a csomag ezt a mezőt követő részének hossza
• slave eszköz  címe — a szolga eszköz címe, amelyhez a kérés címzett. Általában figyelmen kívül hagyják, ha már létrejött a kapcsolat egy adott eszközzel, vagy csak egy eszköz van a rendszerben. Használható, ha a kapcsolat fizikailag csatlakoztatott hídhoz, például RS-485 hálózathoz jön létre.

Meg kell jegyezni, hogy a Modbus TCP-ben nincs hibaellenőrző mező, mivel az adatok integritását a TCP / IP verem biztosítja.

A funkciókódok kategóriái

A jelenlegi protokollspecifikáció a funkciókódok három kategóriáját határozza meg:

Szabványos parancsok Leírásukat a Modbus-IDA-nak közzé kell tennie és jóvá kell hagynia. Ez a kategória magában foglalja a már definiált és jelenleg nem használt kódokat is. Egyéni parancsok Két kódtartomány (65-72 és 100-110), amelyekhez a felhasználó tetszőleges funkciót rendelhet. Nem garantált azonban, hogy más eszközök nem használják ugyanazt a kódot egy másik funkció végrehajtására. fenntartott Ebbe a kategóriába tartoznak azok a funkciókódok, amelyek nem szabványosak, de a különböző cégek által gyártott készülékekben már használatosak. Ezek a 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 és 127 kódok.

Adatmodell

A protokoll egyik tipikus felhasználási módja az adatok olvasása és írása a vezérlőregiszterekbe. A protokoll specifikációja négy adattáblát határoz meg:

asztal	Tárgy típusa	Hozzáférés típusa
Zászlóregiszterek ( tekercsek )	egy kicsit	Olvass és írj
Diszkrét bemenetek _	egy kicsit	csak olvasni
Bemeneti regiszterek _	16 bites szó	csak olvasni
Birtoknyilvántartások _ _	16 bites szó	Olvass és írj

Az egyes táblák elemei 16 bites címmel érhetők el, az első cella a 0. Így minden tábla legfeljebb 65536 elemet tartalmazhat. A specifikáció nem határozza meg, hogy fizikailag melyek legyenek a táblázatelemek, és milyen belső eszközcímeken legyenek elérhetők. Például elfogadható az egymást átfedő táblázatok rendezése. Ebben az esetben a diszkrét adatokkal és 16 bites regiszterekkel működő utasítások ténylegesen ugyanazokhoz az adatokhoz férnek hozzá.

Némi zűrzavar társul az adatok kezelésének módjához. A Modbus eredetileg Modicon vezérlőkhöz lett kifejlesztve. Ezekben a vezérlőkben minden táblázathoz külön számozást használtak. Például az első bemeneti regiszter a 30001 helyszámú, az első tartási regiszter pedig a 40001 volt. Így a Modbus parancsban a 107-es tárolóregiszter-cím a vezérlő 40108-as regiszterszáma volt. Bár az ilyen címegyeztetés már nem része a szabványnak, egyes szoftvercsomagok képesek automatikusan "javítani" a felhasználó által beírt címeket, például úgy, hogy a tárolóregiszter-címből levonják a 40001-et. Referencia kézikönyv 1996-ból https://modbus.org/docs/PI_MBUS_300.pdf , ahol implicit módon hasonló címzést alkalmaztak, elavultként jelölve ("elavult" és "CSAK RÖGÖLT ALKALMAZÁSOKHOZ"), a jelenlegi protokoll specifikáció https:// modbus. org/docs/Modbus_Application_Protocol_V1_1b3.pdf csak abszolút címzést használ - 01 (0x01) Olvasási tekercsek 0x0000 - 0xFFFF, 03 (0x03) 0x0000 - 0xFFFF tárolóregiszterek olvasása.

Szabványos Modbus protokoll funkciók

Adathozzáférés

Adatok olvasása

A fent felsorolt ​​adattáblázatok értékeinek kiolvasásához használja az 1-4 függvénykódokat ( hexadecimális értékek 0x01-0x04):

• 1 (0x01)  - értékek olvasása több jelzőregiszterből (Read Coil Status) .
• 2 (0x02)  - értékek leolvasása több diszkrét bemenetről (Read Discrete Inputs) .
• 3 (0x03)  - Értékek kiolvasása több tartási regiszterből (Read Holding Registers) .
• 4 (0x04)  - Értékek olvasása több bemeneti regiszterből (Read Input Registers) .

A lekérdezés a táblázat első elemének címéből, amelynek értékét be kell olvasni, és az olvasandó elemek számából áll. A címet és az adatmennyiséget 16 bites számként adjuk meg, mindegyikből a legjelentősebb bájt kerül először továbbításra.

A kért adatokat a válaszban elküldjük. Az adatok bájtjainak száma a kért elemek számától függ. Az adatok előtt egy bájt kerül átvitelre, amelynek értéke megegyezik az adatbájtok számával.

A tárolóregiszterek és a bemeneti regiszterek értékei a megadott címtől kezdve, regiszterenként két bájttal kerülnek átvitelre, először minden regiszter magas bájtja:

1. bájt	2. bájt	3. bájt	4. bájt	…	N-1 bájt	bájt N
R A,1	R A,0	R A+1.1	R A+1,0	…	R A+Q-1.1	R A+Q-1,0

A zászlók és a digitális bemenetek értékei csomagolt formában kerülnek továbbításra: zászlónként egy bit. Az egyik azt jelenti, hogy be van kapcsolva, a nulla azt jelenti, hogy kikapcsolt. A kért jelzők értékei először az első bájtot töltik ki, a legkisebb jelentőségű bittel kezdve, majd a következő bájtokat, szintén a legkisebb jelentőségű bittől a legjelentősebbekig. Az első adatbájt legkisebb jelentőségű bitje a "cím" mezőben megadott flag értékét tartalmazza. Ha a jelzők kért száma nem nyolcszoros, akkor az extra bitek értékeit nullákkal töltjük fel:

1. bájt								…	bájt N
F A+7	F A+6	F A+5	F A+4	F A+3	F A+2	F A+1	F A	…	0	…	0	F A+Q-1	F A+Q-2	…

Egyetlen érték rögzítése

• 5 (0x05)  - írja be egy zászló értékét (Force Single Coil) .
• 6 (0x06)  - érték írása egy tárolóregiszterbe (Előre beállított egyetlen regiszter) .

A parancs az elem címéből (2 bájt) és a beállított értékből (2 bájt) áll.

Egy holdingregiszter esetében az érték egyszerűen egy 16 bites szó.

A jelzők esetében a 0xFF00 érték bekapcsolt, a 0x0000 kikapcsolt értéket jelenti, a többi érték érvénytelen.

Ha a parancs sikeres, a slave visszaküldi a kérés másolatát.

Több érték rögzítése

• 15 (0x0F)  - Írjon értékeket több jelzőregiszterbe (több tekercs kényszerítése)
• 16 (0x10)  - értékek írása több tárolóregiszterbe (előre beállított több regiszter)

A parancs az elem címéből, a módosítandó elemek számából, a továbbítandó beállított értékek bájtjaiból és magukból a beállított értékekből áll. Az adatok csomagolása ugyanúgy történik, mint az adatolvasási parancsokban.

A válasz a kiindulási címből és a megváltozott elemek számából áll.

Regiszterek megváltoztatása

• 22 (0x16) - írás egy tárolóregiszterbe az "AND" maszk és az "OR" maszk (Mask Write Register) használatával .

A parancs egy regiszter címéből és két 16 bites számból áll, amelyek maszkként használhatók a regiszter egyedi bitjeinek visszaállítására vagy beállítására. A végeredményt a következő képlet határozza meg:

Eredmény = ( Jelenlegi_érték ÉS Maszk_ÉS ) VAGY ( Maszk_VAGY ÉS (NEM maszk_ÉS ))

Olvasás írással

• 23 (0x17)  - több regiszter olvasása/írása (Több regiszter olvasása/írása )

Ez a funkciókód egy olvasási és egy írási művelet kombinációját hajtja végre egy Modbus tranzakcióban.

Adatsorok

• 24 (0x18) - adatok olvasása a sorból (FIFO-sor olvasása)

A funkciót úgy tervezték, hogy 16 bites szavakat fogadjon egy first-in-first-out ( FIFO ) sorból.

Fájl hozzáférés

• 20 (0x14) - olvasás fájlból (Read File Record)
• 21 (0x15) - írás fájlba (Write File Record)

Ezek a funkciók tetszőleges hosszúságú rekordokba rendezett 16 bites regiszterek elérésére szolgálnak . A parancs 16 bites szavakban adja meg a fájl számát, a rekord számát és a rekord hosszát. Egyetlen paranccsal több rekordot írhat vagy olvashat, nem feltétlenül szomszédosakat.

Ezenkívül a parancs egy egybájtos kódot tartalmaz az adathivatkozás típusának jelzésére. A szabvány jelenlegi verziója csak egy típust határoz meg (a fentebb leírtak szerint) 0x06 kóddal.

Diagnosztika

Az alább felsorolt ​​funkciók soros vonalon (Modbus RTU és Modbus ASCII) lévő eszközökre vonatkoznak.

• 7 (0x07) – állapotjelek olvasása (Kivétel állapotának olvasása)

A funkció célja, hogy információkat szerezzen a távoli eszköz állapotjelzőiről. A függvény egy bájtot ad vissza, amelynek minden bitje egy indikátor állapotának felel meg.

• 8 (0x08) - diagnosztika (diagnosztikai)
• 11 (0x0B) - az eseményszámláló leolvasása (Get Com Event Counter)
• 12 (0x0C) – az eseménynapló olvasása (Get Com Event Log)

Ezek a funkciók a soros kapcsolat működőképességének tesztelésére szolgálnak.

• 17 (0x11) - eszközinformációk olvasása (jelentéskiszolgáló azonosítója)

A funkció célja, hogy információkat szerezzen az eszköz típusáról és állapotáról. A válasz formátuma az eszköztől függ.

Egyéb

• 43 (0x2B) – Encapsulated Interface Transport

A funkciót úgy tervezték, hogy tetszőleges (más szabványok által meghatározott) formátumban továbbítsa az adatokat a mesterről (kliensről) a slave-re (szerverre) és fordítva.

A továbbított adatok típusát a funkciószám után továbbított kiegészítő kód (MEI - Modbus Encapsulated Interface) határozza meg. A szabvány a MEI 13-at (0x0D) határozza meg, amelynek célja a CANopen protokoll beágyazása . A MEI 14 (0x0E) az eszközinformációk lekérésére szolgál, a 0-12 és 15-255 tartományba eső MEI-k pedig le vannak foglalva.

Hibakezelés

A kommunikáció során kétféle hiba fordulhat elő:

• az adatátvitel torzulásával kapcsolatos hibák;
• logikai hibák (a kérést torzítás nélkül elfogadjuk, de nem hajtható végre)

Aszinkron kommunikációs vonalakon keresztül történő átvitel során az első típusú hibákat a fogadott kérés beállított ADU formátumnak való megfelelőségének ellenőrzésével és az ellenőrző összeg kiszámításával észleljük. Ezenkívül egy paritásbit is használható az egyes karakterek ellenőrzésére . Ha a slave adatsérülést észlel, a kapott kérést figyelmen kívül hagyja, és nem generál válaszüzenetet. A gazdagép képes észlelni a nincs válasz hibát.

A Modbus TCP nem biztosít további adatintegritás-ellenőrzést. A torzításmentes adatátvitelt a TCP/IP protokollok biztosítják.

A második típusú hibák esetén a szolga eszköz hibaüzenetet küld (ha a kérés ennek az eszköznek szól, nem küld választ a broadcast kérésekre). Azt jelzi, hogy a válasz hibaüzenetet tartalmaz, a függvényszám beállított magas bitje. A funkciószámot a hibakód és szükség esetén a szokásos adatok helyett további hibaadatok követik.

Szabványos hibakódok

• 01 - A fogadott funkciókódot nem sikerült feldolgozni.
• 02 - A kérelemben megadott adatcím nem elérhető.
• 03 - A kérés adatmezőjében szereplő érték érvénytelen.
• 04 - Helyrehozhatatlan hiba történt, miközben a slave megpróbálta végrehajtani a kért műveletet.
• 05 - A szolgaeszköz megkapta a kérést és feldolgozza azt, de ez sokáig tart. Ez a válasz megakadályozza, hogy a mester időtúllépési hibát generáljon.
• 06 - A slave eszköz a parancs feldolgozásával van elfoglalva. A masternek meg kell ismételnie az üzenetet később, amikor a slave szabad lesz.
• 07 - A szolga eszköz nem tudja végrehajtani a kérésben megadott programfunkciót. Ezt a kódot ad vissza sikertelen programkérés esetén a 13-as vagy 14-es funkciószámmal. A masternek diagnosztikai vagy hibainformációt kell kérnie a slave-től.
• 08 - A slave eszköz paritáshibát észlelt a kiterjesztett memória beolvasása közben. A mester később megismételheti a kérést, de általában ilyen esetekben a berendezés javítása szükséges.

Példák

Az alábbiakban egy példa látható a master parancsra és a slave válaszokra (Modbus RTU-hoz).

Kérés
Átviteli irány	slave eszköz címe	funkció száma	Cím		A zászlók száma		Adatbájtok száma	Adat		CRC
			magas bájt	alacsony bájt	magas bájt	alacsony bájt		magas bájt	alacsony bájt	alacsony bájt	magas bájt
Kliens → Szerver	0x01	0x0F	0x00	0x13	0x00	0x0A	0x02	0xCD	0x01	0x72	0xCB

Válasz
Átviteli irány	slave eszköz címe	funkció száma	Cím		A zászlók száma		CRC
			magas bájt	alacsony bájt	magas bájt	alacsony bájt	alacsony bájt	magas bájt
Szerver→ Kliens	0x01	0x0F	0x00	0x13	0x00	0x0A	0x24	0x09
Hiba üzenet
Átviteli irány	slave eszköz címe	funkció száma	hibakód	CRC
				alacsony bájt	magas bájt
Szerver→ Kliens	0x01	0x8F	0x02	0xC5	0xF1

Jegyzetek

1. ↑ A Modbus Protokoll részletes leírása. Archiválva : 2017. június 29. a Wayback Machine National Instruments -nél
2. ↑ Modbus UDP specifikáció. Archiválva 2017. július 7-én a Wayback Machine Java Modbus Library -ben
3. ↑ PROMOTIC – Kommunikáció Modbus protokollal . Letöltve: 2015. július 7. Az eredetiből archiválva : 2015. július 8.. (határozatlan)
4. ↑ 1 2 Modbus interfész oktatóanyag . Letöltve: 2009. március 23. Az eredetiből archiválva : 2011. március 3.. (határozatlan)
5. ↑ A Modbus-IDA-ról . Letöltve: 2009. március 23. Az eredetiből archiválva : 2016. március 3.. (határozatlan)
6. ↑ Charles Palmer, Sujeet Shenoi (szerk.) Critical Infrastructure Protection III: Harmadik IFIP WG 11. 10 Nemzetközi Konferencia, Hannover, New Hampshire, USA, 2009. március 23-25., Revised Selected Papers Springer, 2009 ISBN 3-6947-047 1 , 87. oldal
7. ↑ 1 2 3 4 Alkalmazásfejlesztés Modbus segítségével . Letöltve: 2015. július 7. Az eredetiből archiválva : 2015. július 8.. (határozatlan)

Irodalom

• Eredeti angol nyelvű protokoll specifikációk
• Modbus specifikációk és megvalósítási útmutatók (Modbus TCP/IP)

Linkek

• A Modbus-IDA egy non-profit szervezet, amely támogatja ezt a protokollt
• Adatgyűjtés és -ellenőrzés: adatkommunikáció a Curlie Links Directory-nál (dmoz)
• Adatgyűjtés és -vezérlés: Szoftver a Curlie Link Directory-nál (dmoz)

UART
Fizikai rétegek	pontról pontra RS-232 IrDA SZARVASBIKA modem áramhurok IRPS MIDI IO-Link (IEC 61131-9) Hálózat RS-422 RS-423 RS-485 LIN M busz Különleges Kansas City szabvány Kompakt kazetta gramofon lemez
Protokollok	pontról pontra PPP CSÚSZÁS IrDA SZARVASBIKA ISO 7816 MIDI IO-Link (IEC 61131-9) Hálózat Modbus LIN DMX-512 P-NET Profibus IEC 60870
Felhasználási területek	Soros port IrDA MIDI ipari hálózat
Megvalósítások	Vezérlők 8250 UART 16550 UART Drivers MAX232