20. fejezet – Modbus TCP és Modbus RTU

A könyv gyakorló busza: négy tábla, nyolc funkciókód, és minden, amit a kezdők el szoktak rontani.

Ebben a fejezetben
  1. 20.1 Miért a Modbus a gyakorló busz?
  2. 20.2 A négy elsődleges tábla
  3. 20.3 Címzés: a nulla, ami mindig hiányzik
  4. 20.4 Funkciókódok
  5. 20.5 A keret: PDU és ADU
  6. 20.6 Modbus RTU: master, slave, broadcast
  7. 20.7 Az RTU időzítése — miért nincs keretkezdő jel?
  8. 20.8 Az RS-485 fizikai réteg
  9. 20.9 Modbus TCP
  10. 20.10 A CC100 mint Modbus-eszköz
  11. 20.11 A CODESYS Modbus-konfigurációja
  12. 20.12 A %IW/%QW hozzárendelés — miért tűnik fordítottnak?
  13. 20.13 Hibakeresés Modbus-vonalon
  14. Összefoglalás
  15. Gyakorlatok
  16. Ellenőrző kérdések
  17. Tudáspróba
  18. A fejezet forrásai

Az előző fejezet elméletben mutatta be az ipari buszokat. Ez a fejezet gyakorlati: a Modbust olyan részletességgel dolgozza fel, hogy a következő fejezetben már valódi eszközt tudj ráilleszteni a CC100-ra.

A Modbus a legjobb tanulóbusz, amit találhatnánk. Nem azért, mert a legmodernebb — hanem azért, mert átlátható: az adatmodellje elfér egy ábrán, a keretei kézzel is kiszámolhatók, és a hibái megérthetők. A PROFINET vagy az EtherCAT működését kezdő szinten csak elhinni lehet; a Modbusét be lehet látni.

20.1 Miért a Modbus a gyakorló busz?

Két oka van, és mindkettő komoly.

Az eszközpark. A CC100 gyártói adatlapja szerint a vezérlő Modbus TCP/UDP és Modbus RTU protokollt támogat,1 és van hozzá RS-485 portja is (115 200 baud, félduplex).2 Vagyis mindkét Modbus-világ elérhető ugyanazon a készüléken, extra hardver nélkül.

A didaktika. A Modbus regisztermodellje olyan egyszerű, hogy egy A4-es lapon elfér — de elég gazdag ahhoz, hogy minden fontos buszfogalmat megtanulj rajta: címzés, funkciókód, keretezés, időzítés, hibakezelés, master–slave viszony.

💡 Amit itt tanulsz, máshol is ér

Az RS-485-ről szóló alfejezet szó szerint érvényes a PROFIBUS-ra is (19. fejezet), a kérés-válasz gondolkodás pedig minden buszon ugyanaz. A Modbus nem zsákutca, hanem alapozás.

20.2 A négy elsődleges tábla

A Modbus nem egyetlen, összefüggő memóriaterület. Négy külön tábla van benne, és a specifikáció ezeket „elsődleges tábláknak” (primary tables) nevezi:3

Tábla Magyar név Objektum Hozzáférés Tipikus tartalom
Discrete Inputs diszkrét bemenetek 1 bit csak olvasható digitális bemenetek állapota
Coils tekercsek 1 bit írható-olvasható digitális kimenetek
Input Registers bemeneti regiszterek 16 bites szó csak olvasható analóg bemenetek, mérési adat
Holding Registers tartóregiszterek 16 bites szó írható-olvasható paraméterek, alapjelek, analóg kimenetek
A Modbus adatmodell négy táblája és a hozzájuk tartozó funkciókódok 1 bit 16 bites szó csak olvasható írható és olvasható Discrete Inputs diszkrét bemenetek digitális bemenetek állapota 02 — Read Discrete Inputs Input Registers bemeneti regiszterek analóg bemenetek, mérési adat 04 — Read Input Registers Coils tekercsek digitális kimenetek 01 — Read Coils 05 — egy 15 — több Holding Registers tartóregiszterek paraméterek, alapjelek, analóg ki 03 — Read Holding Registers 06 — egy 16 — több A tábla dönti el, hogy bit vagy szó, és hogy írható-e. Nem „a Modbus-címre” írsz, hanem egy adott tábla egy adott elemére.
20.1. ábra. A négy elsődleges tábla és a hozzájuk tartozó funkciókódok. A táblák szétválasztása a bit/szó és az olvasható/írható tengely mentén történik.

A négyes felosztás mögött két kérdés áll:

  1. bit vagy szó? — egyetlen logikai jel, vagy egy 16 bites érték;
  2. írható vagy csak olvasható? — beavatkozhat-e a másik oldal, vagy csak megfigyel.
⚠️ A leggyakoribb kezdői hiba

Nem „a Modbus-címre” írsz, hanem egy adott tábla egy adott elemére. Ha a dokumentáció szerint valami a bemeneti regiszterek között van, akkor azt hiába próbálod írni: a tábla csak olvasható, és ezt nem a szoftver döntötte el, hanem a protokoll.

A „tekercs” (coil) elnevezés a relés múltból maradt ránk: valamikor tényleg egy relé tekercse volt a másik végén. Ma minden 1 bites, írható kimenetet így hívunk.

20.3 Címzés: a nulla, ami mindig hiányzik

Itt következik a Modbus egyetlen legköltségesebb félreértése.

A specifikáció két dolgot mond ki, és a kettő nem ugyanaz:

„a MODBUS adatmodell 4 blokkból áll, amelyek 1-től n-ig számozott elemeket tartalmaznak”3

„Egy MODBUS PDU-ban minden adat 0-tól 65535-ig címzett.”3

Vagyis: az elemek 1-től vannak számozva, a PDU 0-tól címez. A specifikáció ezt minden érintett funkciókódnál külön ki is mondja:

„A PDU-ban a tekercsek nullától kezdve címzettek. Ezért az 1–16-os számú tekercsek 0–15-ként címzettek.”3

Az egyes eltolódás: 1-től számozott elem, 0-tól címzett PDU adatmodell (1-től n-ig) 123 456 … −1 PDU-cím (0-tól 65535-ig) 012 345 … A specifikáció szó szerint: „coils numbered 1-16 are addressed as 0-15”. A leképezés a modell és a valódi jelek között viszont „totally vendor device specific”: a gyártó dokumentációja nélkül nem lehet kitalálni, melyik jel melyik címen van. Az elterjedt „4xxxx / 3xxxx” jelölést a specifikáció nem definiálja — mérésből derül ki.
20.2. ábra. Az egyes eltolódás. Ami a dokumentációban az 1. elem, az a kereten belül a 0. cím.
📗 Egyes eltolódás (off-by-one)

A Modbus-dokumentációk gyakran a modellbeli sorszámot (1-től) adják meg, a fejlesztői környezet viszont a PDU-címet (0-tól) kéri. A kettő között mindig egy a különbség — és ez az egy okozza a beüzemelések legtöbb elveszett óráját.

Van egy még kellemetlenebb pont is. A specifikáció szó szerint kimondja:

„A MODBUS adatmodell és az eszközalkalmazás közötti előleképezés teljes egészében eszközfüggő.”3

Azaz melyik fizikai bemenet melyik táblában, hányadik elemként jelenik meg, azt kizárólag a gyártó dönti el. Ezt nem lehet kitalálni, nem lehet kikövetkeztetni — csak elolvasni vagy megmérni.

⚠️ A „4xxxx” jelölésről

Sok gyártói dokumentáció 40001, 30001, 10001 alakú számokat használ, ahol az első számjegy a táblát jelöli. Ezt a jelölést a Modbus-specifikáció nem definiálja — elterjedt ipari szokás, nem szabvány. Ezért a könyv nem ad rá általános átváltási szabályt: a 21. fejezetben méréssel oldjuk fel egy konkrét eszköz jelölését.

20.4 Funkciókódok

A Modbus „kérés-válasz protokoll, amely funkciókódokkal meghatározott szolgáltatásokat nyújt”.3 A gyakorlati munka döntő részét nyolc kód fedi le:

Kód Név Magyarul Melyik táblát éri el?
01 (0x01) Read Coils tekercsek olvasása Coils
02 (0x02) Read Discrete Inputs diszkrét bemenetek olvasása Discrete Inputs
03 (0x03) Read Holding Registers tartóregiszterek olvasása Holding Registers
04 (0x04) Read Input Registers bemeneti regiszterek olvasása Input Registers
05 (0x05) Write Single Coil egy tekercs írása Coils
06 (0x06) Write Single Register egy regiszter írása Holding Registers
15 (0x0F) Write Multiple Coils több tekercs írása Coils
16 (0x10) Write Multiple Registers több regiszter írása Holding Registers
💡 Memoriter

Az olvasó kódok: 01–04. Az író kódok: 05 és 06 egyet, 15 és 16 többet ír. Írni csak a két írható táblába lehet — ezért nincs „írd a bemeneti regisztert” funkciókód.

Figyeld meg a szimmetriát: mind a négy táblához van olvasó kód, de csak a két írható táblához van író kód. A funkciókódok listája maga is elmondja az adatmodellt.

20.5 A keret: PDU és ADU

A Modbus két rétegben gondolkodik. A PDU (protocol data unit) a funkciókód és az adat — ez minden átviteli közegen ugyanaz. Az ADU (application data unit) a PDU plusz a közegtől függő burkolat.

A specifikáció ezt számokkal is megadja:3

„MODBUS PDU soros vonali kommunikációhoz = 256 − szervercím (1 bájt) − CRC (2 bájt) = 253 bájt.”

„TCP MODBUS ADU = 253 bájt + MBAP (7 bájt) = 260 bájt.”

Réteg Méret Miből áll?
soros vonali ADU 256 bájt cím (1) + PDU (253) + CRC (2)
PDU 253 bájt funkciókód (1) + adat (max. 252)
TCP-s ADU 260 bájt MBAP-fejléc (7) + PDU (253)
Ugyanaz a PDU, kétféle csomagolásban Modbus RTU (soros vonal) — ADU = 256 bájt cím 1 bájt PDU — funkciókód + adat 253 bájt CRC 2 bájt 256 − 1 − 2 = 253 Modbus TCP — ADU = 260 bájt, a 502-es porton TransactionProtocol LengthUnit ID 2 bájt2 bájt (0) 2 bájt1 bájt PDU — funkciókód + adat 253 bájt MBAP-fejléc: 2 + 2 + 2 + 1 = 7 bájt 253 + 7 = 260 A TCP-nél nincs CRC és nincs slave-cím a keretben — a hibaellenőrzést és a keretezést a TCP végzi. A Unit ID mégis megmarad: átjárón át egy soros vonali slave-hez irányítja az üzenetet.
20.3. ábra. Ugyanaz a PDU két csomagolásban. A soros változat maga gondoskodik a címről és a hibaellenőrzésről, a TCP-s ezt a hálózatra bízza.

Ellenőrizd le magad: 256 − 1 − 2 = 253, és 253 + 7 = 260. A két szám konzisztens — és ez nem véletlen, hanem a specifikáció szándéka: a PDU mérete azért 253, hogy a soros keret beleférjen 256 bájtba.

💡 Miért fontos a 253-as korlát?

Mert ez határolja be, hány regisztert kérdezhetsz le egyetlen kéréssel. Ha egy eszközből 500 regisztert akarsz kiolvasni, azt nem lehet egy kérésben — több csatornára kell bontani. Ez a szám tehát nem trivia, hanem tervezési adat.

20.6 Modbus RTU: master, slave, broadcast

A soros vonali Modbus szigorúan egy masteres:

„Egyszerre csak egy master csatlakozik a buszra, és egy vagy több (legfeljebb 247) slave csomópont csatlakozik ugyanarra a soros buszra.”4

Fogalom Érték
Master egyszerre egy4
Slave-ek száma legfeljebb 2474
Slave-címek 1–2474
0-s cím fenntartva a broadcast (körüzenet) számára4

A broadcastnak van egy fontos következménye: körüzenetre nem érkezik válasz. Ha egy paranccsal minden slave-nek szólsz, nem tudod meg, végrehajtották-e.

Az RTU keret

A keret felépítése: slave-cím → funkciókód → adat → CRC (2 bájt).4

20.7 Az RTU időzítése — miért nincs keretkezdő jel?

Ez a Modbus RTU legérdekesebb és leggyakrabban félreértett tulajdonsága.

A keretnek nincs kezdő- és nincs zárókaraktere. Honnan tudja akkor a vevő, hol kezdődik egy üzenet? Az időből.4

  • A kereteket legalább 3,5 karakteridőnyi csend választja el egymástól (t3,5).
  • A kereten belül az 1,5 karakteridőnél hosszabb csend azt jelenti, hogy az üzenet hiányos (t1,5).
A Modbus RTU keretét kizárólag az időzítés határolja csend ≥ t3,5 slave-cím 1 bájt funkciókód 1 bájt adat 0…252 bájt CRC 2 bájt csend ≥ t3,5 egy keret — a PDU legfeljebb 253 bájt, az ADU 256 A kereten BELÜL > t1,5 csend = hiányos üzenet Az RTU keretnek nincs kezdő- és nincs zárókaraktere. Ha valami megnyújtja a karakterek közötti szünetet — rossz átalakító, nem valós idejű USB-konverter, terhelt gép —, a vevő kettévágja a keretet, és „minden jól van bekötve, mégsem megy”.
20.4. ábra. Az RTU keretezés kizárólag időzítésen alapul: a keret előtt és után csend van, a kereten belül nem lehet szünet.
⚠️ Ezért nem működik néha „a jól bekötött” busz

Mivel a keret határa kizárólag időzítés, minden, ami megnyújtja a karakterek közötti szünetet, kettévágja az üzenetet: egy nem valós idejű USB–RS-485 átalakító, egy pufferelő konverter, egy túlterhelt operációs rendszer. A tünet klasszikus: „minden jól van bekötve, mégis hibás a kommunikáció.” A megoldás nem a kábel cseréje, hanem a konverter megválasztása.

Az ASCII mód — összehasonlításként

Létezik egy másik soros mód is: az ASCII. Ott a keret kettősponttal (:) kezdődik, CR LF-fel záródik, és a hibaellenőrzés 8 bites LRC, nem CRC.4 Cserébe minden bájtot két karakterrel ír le, tehát kétszer annyi adatot küld. Emberi szemmel olvashatóbb, de lassabb — a gyakorlatban ritkán találkozol vele.

Átviteli beállítások

Paraméter Érték
Kötelezően támogatandó sebességek 9600 és 19 200 bit/s4
Alapértelmezés 19 200 bit/s4
RTU karakterformátum 1 start bit, 8 adatbit (a legkisebb helyértékű elöl), 1 paritásbit, 1 stopbit4
Paritás páros paritás kötelező4

A CC100 RS-485 portja ennél jóval többet tud: 115 200 baud, félduplex.2

⚠️ A négy beállítás, aminek egyeznie kell

Sebesség, adatbitek száma, paritás, stopbit. Ha ezek közül bármelyik eltér a master és a slave között, a kommunikáció nem jön létre — és jellemzően nem is kapsz értelmes hibaüzenetet, csak időtúllépést.

20.8 Az RS-485 fizikai réteg

Téma Adat
Kétvezetékes kialakítás szimmetrikus érpár (D0, D1) + közös föld4
Négyvezetékes kialakítás külön master- és slave-érpár (TXD0/TXD1, RXD0/RXD1)4
Vonalvégi lezárás 150 Ω / 0,5 W ellenállás a törzsvonal két végén4
Vonalpolarizáció 450–650 Ω felhúzó/lehúzó ellenállás, ha szükséges4

A CC100 RS-485 portja D+, D–, GNDRS és SHRS lábakkal kétvezetékes kialakítású (7. fejezet).2

Kétvezetékes RS-485 busz lezárással és közös földdel D1 / D+ D0 / D− közös föld 150 Ω 150 Ω CC100 master slave 1 slave 2 cím: 1 cím: 2 A két klasszikus hibaforrás: hiányzó lezárás a vonal végein, és hiányzó közös föld. Mindkettő „néha működik” állapotot okoz — ami rosszabb, mint ha egyáltalán nem menne.
20.5. ábra. Kétvezetékes RS-485 busz. A lezárás a vonal két végére kerül — nem minden eszközhöz.
⚠️ Két hiba, amit szinte mindenki elkövet

1. A lezárás elhagyása vagy rossz helyre tétele. A 150 Ω-os ellenállás a törzsvonal két végére való, nem minden eszközhöz. Középre tett lezárás ugyanolyan rossz, mint a hiányzó.

2. A közös föld elhagyása. Az RS-485 szimmetrikus jelátvitel, de a két eszköz földpotenciáljának a közös módusú tartományon belül kell maradnia. Közös föld nélkül a busz rövid távon működhet, hosszabb távon vagy zajos környezetben viszont véletlenszerűen hibázik.

Mindkét hiba ugyanazt a legrosszabb tünetet adja: a rendszer néha működik.

20.9 Modbus TCP

A TCP-s változat ugyanazt a PDU-t viszi, de a soros keretezést és a CRC-t a TCP váltja ki. A burkolat neve MBAP-fejléc.

„Minden MODBUS/TCP ADU-t TCP-n keresztül, a regisztrált 502-es portra küldenek.”7

MBAP-mező Hossz Jelentés
Transaction Identifier 2 bájt „a MODBUS kérés-válasz tranzakció azonosítása”7
Protocol Identifier 2 bájt „0 = MODBUS protokoll”7
Length 2 bájt „a következő bájtok száma”7
Unit Identifier 1 bájt „a távoli slave azonosítása soros vonalon vagy más buszon”7

Számold össze: 2 + 2 + 2 + 1 = 7 bájt — pontosan annyi, amennyi a 260 és a 253 közötti különbség. A két specifikáció számszerűen egyezik.

A Unit Identifier — amit sokan félreértenek

Gyakran hallani, hogy „Modbus TCP-n nincs slave-cím”. Van — csak nem a keretezéshez kell:

„Ez a mező rendszeren belüli útvonalválasztásra szolgál. Jellemzően arra használják, hogy egy Ethernet TCP/IP-hálózat és egy MODBUS soros vonal közötti átjárón keresztül kommunikáljanak egy MODBUS+ vagy MODBUS soros vonali slave-vel.”7

Vagyis a Unit ID akkor válik fontossá, ha az üzenet nem áll meg az Ethernet-eszköznél, hanem azon túl, egy soros buszon lévő eszköznek szól. Ha közvetlenül egy Modbus TCP-s eszközzel beszélsz, a mező jellemzően közömbös — de a gyártó megkövetelhet egy adott értéket, ezért mindig nézd meg a dokumentációt.

💡 Így kapcsolódik össze a két világ

A Unit ID az a fogalmi híd, amely a TCP-s és az RTU-s Modbust összeköti. Ha ezt megérted, akkor egy „Modbus TCP ↔ Modbus RTU átjáró” működése sem lesz rejtély: az átjáró kicsomagolja az MBAP-fejlécet, a Unit ID-ból slave-címet csinál, kiszámolja a CRC-t, és kiküldi az RS-485-re.

20.10 A CC100 mint Modbus-eszköz

A CC100 mindkét szerepben és mindkét közegen működhet:1 2

Szerep Közeg Mit jelent?
Kliens (master) TCP a CC100 kérdez le más eszközöket — ez lesz a 21. fejezet
Szerver (slave) TCP a CC100 adatait egy felügyeleti rendszer olvassa
Master RTU (RS-485) soros vonali eszközök lekérdezése
Slave RTU (RS-485) a CC100 egy másik master alárendeltje

A gyártói adatlap a Modbus TCP mellett Modbus UDP-t is megnevez.1 Ez a könyvben nem kap külön alfejezetet: az UDP nem garantálja a kézbesítést, ezért vezérlési feladatra ritkán választják.

20.11 A CODESYS Modbus-konfigurációja

A CODESYS-oldali beállításokból az alábbiakat igazoltuk gyártói dokumentációból.

Modbus TCP Client (a kérdező oldal):5

Beállítás Jelentés
Response Timeout (ms) „az az időköz (ezredmásodpercben), ameddig a kliens a szerver csomópont válaszára vár”
Auto-reconnect „a kliens mindig megkísérli a megszakadt kapcsolat automatikus helyreállítását”

Modbus TCP Server Device (a válaszoló oldal):6

Beállítás Érték / jelentés
Server port „a szerver portszáma”
Bind to Adapter melyik Ethernet-adapterre kapcsolódjon (több adapternél lényeges)
Holding registers (%IW) lehetséges értékek: 1–4096
Input registers (%QW) lehetséges értékek: 1–4096
Coils, Discrete inputs konfigurálható bitterületek
⚠️ Amit a könyv nem tud megmutatni — még

A kliensoldali csatornakonfiguráció részletei (a távoli eszköz IP-címe, Unit ID-ja, a csatorna funkciókódja, offsetje, hossza, a ciklikus vagy éllel kiváltott működés és a ciklusidő) a lekért gyártói súgólapokon nem szerepeltek. Ezeket a 21. fejezet mutatja be, valódi eszközön, képernyőképekkel — nem emlékezetből.

20.12 A %IW/%QW hozzárendelés — miért tűnik fordítottnak?

Nézd meg még egyszer az előző táblázat két sorát:

  • Holding registers → %IW (bemeneti szó)
  • Input registers → %QW (kimeneti szó)

Első ránézésre ez hibának tűnik: a „bemeneti regiszter” miért kimenet?

A válasz a nézőpontban van. A CODESYS-beállítás a szerver saját programja felől értelmezendő:

Miért tűnik fordítottnak a %IW és a %QW a szerver oldalán? Modbus-kliens (master) Modbus-szerver (slave) — pl. a CC100 Holding registers a kliens ÍRJA Input registers a kliens OLVASSA PLC- program írás %IW — bemenet %QW — kimenet olvasás Nem a Modbus fordult meg, hanem a nézőpont: a hozzárendelés a szerver programjából nézve érvényes. Amit a kliens beleír (holding), az a program felé bemenet → %IW. Amit a kliens kiolvas (input), azt a programnak elő kell állítania → %QW.
20.6. ábra. A hozzárendelés a szerver programja felől nézve logikus: amit a kliens ír, az a programnak bemenet.
  • A holding registert a kliens írja. A szerver programja szempontjából ez kívülről érkező adat — tehát bemenet, %IW.
  • Az input registert a kliens olvassa. Ezt az értéket a szerver programjának elő kell állítania — tehát ez a program kimenete, %QW.
💡 Egy mondatban

A tábla nevét a kliens szemszögéből adták, a CODESYS címterületét viszont a szerver programja szemszögéből. Nem a Modbus fordult meg — a nézőpont.

⚠️ Ez a magyarázat a könyv saját levezetése

A %IW/%QW hozzárendelés ténye gyártói forrásból igazolt.6 A fenti magyarázat viszont a könyv indoklása, nem idézet. A 21. fejezetben gyakorlati próbával ellenőrizzük: beírunk egy értéket kívülről, és megnézzük, melyik változóban jelenik meg.

20.13 Hibakeresés Modbus-vonalon

Végül a leggyakorlatibb rész: mit csinálj, ha nem megy.

Haladj kívülről befelé, rétegenként.

Réteg Kérdés Hogyan ellenőrzöd?
1. Fizikai van kapcsolat? TCP: link-LED, ping. RTU: bekötés, lezárás, közös föld
2. Átviteli egyeznek a beállítások? RTU: sebesség, paritás, stopbit. TCP: IP-cím, alhálózat, 502-es port
3. Címzés jó eszközt kérdezel? RTU: slave-cím. TCP: IP + Unit ID
4. Protokoll jó táblát és címet kérdezel? funkciókód ↔ tábla egyezése, az egyes eltolódás
5. Alkalmazás értelmes az adat? bájtsorrend, előjel, skálázás

Tipikus hibák és mit jelentenek:

Tünet Valószínű ok
Időtúllépés (nincs válasz) rossz cím vagy IP; eltérő soros beállítások; kábelhiba; a slave nem fut
Kivételválasz (exception) a kért funkciókódot nem támogatja; a cím a tartományon kívül van; írható-e egyáltalán
Adat érkezik, de értelmetlen az egyes eltolódás; rossz tábla; bájtsorrend vagy skálázás
Néha működik RS-485 lezárás vagy közös föld hiánya; időzítési (t1,5) probléma a konverternél
💡 Az utolsó tünet a legfontosabb

A „néha működik” sokkal veszélyesebb, mint a „soha nem működik”. Egy nem működő rendszert mindenki megjavít. Egy időnként hibázó rendszert üzembe helyeznek — és hónapokkal később, a legrosszabb pillanatban áll le. Ha ilyet tapasztalsz, ne örülj annak, hogy „általában jó”: keresd meg az okát.

Összefoglalás

  • A Modbus négy elsődleges táblát használ: diszkrét bemenetek és tekercsek (1 bit), bemeneti és tartóregiszterek (16 bites szó). A tábla dönti el, hogy bit vagy szó, és hogy írható-e.
  • Az adatmodell elemei 1-től számozottak, a PDU 0-tól címez — állandó egyes eltolódás. A leképezés a modell és a valódi jelek között „teljes egészében eszközfüggő”.
  • Nyolc funkciókód (01–06, 15, 16) fedi le a gyakorlati munka döntő részét. Írni csak a két írható táblába lehet.
  • A PDU 253 bájt, a soros ADU 256, a TCP-s ADU 260 (MBAP = 7 bájt). A számok konzisztensek, és tervezési korlátot jelentenek.
  • A Modbus RTU egy masteres, legfeljebb 247 slave-vel; a 0-s cím a broadcasté. A keretet kizárólag az időzítés határolja: t3,5 a keretek között, t1,5 a kereten belül.
  • Az RS-485 két klasszikus hibaforrása a hiányzó 150 Ω-os lezárás és a hiányzó közös föld — mindkettő „néha működik” állapotot okoz.
  • A Modbus TCP a 502-es porton dolgozik; a 7 bájtos MBAP-fejlécben a Unit ID átjárón túli, soros vonali eszközök elérésére szolgál.
  • A CODESYS-ben a szerver holding regisztere %IW, az input regisztere %QW — mert a hozzárendelés a szerver programja felől értelmezendő.
  • Hibakeresésnél haladj rétegenként kívülről befelé, és soha ne hagyd annyiban a „néha működik” tünetet.

Gyakorlatok

🛠️ 20.1. feladat — Számold ki a korlátot

Hány holding regisztert lehet legfeljebb kiolvasni egyetlen 03-as funkciókódú válaszban, ha a válasz PDU-ja funkciókódból (1 bájt), bájtszámlálóból (1 bájt) és a regiszterértékekből (2 bájt/regiszter) áll, és a PDU legfeljebb 253 bájt? Írd le a számítást lépésenként. Utána nézd meg egy Modbus-eszköz adatlapján, hány regisztert enged egy kérésben — egyezik-e az elméleti maximummal, és ha nem, mi lehet az oka?

🛠️ 20.2. feladat — Fordítsd le a címeket

Egy eszköz dokumentációja szerint a hőmérséklet a 3. bemeneti regiszterben, a kapcsolási küszöb a 12. tartóregiszterben található. Add meg mindkettőhöz: (a) a szükséges funkciókódot, (b) a PDU-címet, (c) hogy írható-e. Indokold a válaszaidat a specifikáció címzési szabályára hivatkozva.

🛠️ 20.3. feladat — Időzítés számokkal

Számold ki, mennyi ideig tart egy karakter átvitele 9600 bit/s sebességen, ha egy karakter 1 start + 8 adat + 1 paritás + 1 stop bitből áll. Ebből számold ki a t1,5 és a t3,5 értékét ezredmásodpercben. Ismételd meg a számítást 115 200 bit/s-ra. Fogalmazd meg egy mondatban, miért nehezebb betartani ezeket az időket nagyobb sebességen.

🛠️ 20.4. feladat — Tervezz meg egy buszt

Egy csarnokban hat Modbus RTU-s energiamérőt kell felfűzni a CC100-ra, a legtávolabbi 180 m-re. Rajzold le a busz kapcsolási vázlatát: érpárok, közös föld, lezáróellenállások helye és értéke, slave-címek. Írd fel a beállítandó soros paramétereket. Jelöld meg a rajzon azt a két pontot, ahol a leggyakoribb hiba keletkezik.

🛠️ 20.5. feladat — Készíts hibakeresési döntési fát

A 20.13. alfejezet táblázata alapján rajzolj folyamatábrát (5. fejezet jelölései!) arra, hogyan keresed meg egy nem működő Modbus TCP-kapcsolat hibáját. Minden döntési pontnál nevezd meg, mivel ellenőrzöd az adott feltételt.

Ellenőrző kérdések

  1. Nevezd meg a négy elsődleges táblát, és mondd meg mindegyikről, hogy bit- vagy szóalapú-e, illetve írható-e!
  2. Miért nincs „bemeneti regiszter írása” funkciókód?
  3. Mi az egyes eltolódás, és a specifikáció mely mondatából következik?
  4. Mit jelent az, hogy a leképezés „teljes egészében eszközfüggő”, és milyen gyakorlati következménye van?
  5. Vezesd le, miért 253 bájt a PDU és 260 a TCP-s ADU!
  6. Hány slave lehet egy Modbus RTU-buszon, és mire van fenntartva a 0-s cím?
  7. Magyarázd el a t3,5 és a t1,5 időzítés szerepét! Miért nincs keretkezdő karakter?
  8. Miért okozhat hibát egy nem valós idejű USB–RS-485 átalakító?
  9. Hová kerül a 150 Ω-os lezáróellenállás, és miért pont oda?
  10. Mire való a Unit Identifier Modbus TCP-n?
  11. Miért %IW a holding regiszter a CODESYS szerveroldalán?
  12. Sorold fel a hibakeresés öt rétegét, és mondj mindegyikhez egy ellenőrzési módszert!

Tudáspróba

Válaszd ki az egyetlen helyes választ!

1. Melyik tábla írható és bitalapú? a) Coils b) Discrete Inputs c) Input Registers d) Holding Registers

2. A PDU-ban az adatok címzése: a) 1-től 65 536-ig b) 0-tól 65 535-ig c) 1-től 247-ig d) 0-tól 4095-ig

3. Melyik funkciókód olvas tartóregisztert? a) 01 b) 02 c) 03 d) 04

4. A soros vonali Modbus PDU legnagyobb mérete: a) 246 bájt b) 253 bájt c) 256 bájt d) 260 bájt

5. Hány slave lehet legfeljebb egy Modbus RTU-buszon? a) 32 b) 126 c) 247 d) 255

6. A Modbus RTU-nál a keretek közötti minimális csend: a) 1,5 karakteridő b) nincs ilyen előírás c) 10 ms d) 3,5 karakteridő

7. A Modbus TCP regisztrált portszáma: a) 102 b) 502 c) 2404 d) 44818

8. Az MBAP-fejléc mérete: a) 2 bájt b) 5 bájt c) 7 bájt d) 12 bájt

9. Az RS-485 vonalvégi lezáróellenállás értéke a specifikáció szerint: a) 120 Ω b) 150 Ω c) 450 Ω d) 650 Ω

10. A CODESYS Modbus-szerverén a holding regiszterek címterülete: a) %IW b) %QW c) %MW d) %IX

A megoldókulcs a B függelékben található.

A fejezet forrásai

  1. Compact Controller 100 Data Sheet 751-9301. WAGO. (2026-07-29) ↩↩↩

  2. Manual: WAGO I/O System Compact 751-9301 Compact Controller 100. WAGO. (2026-07-29) Az RS-485 port adatai. ↩↩↩↩

  3. MODBUS Application Protocol Specification V1.1b3 (2012-04-26). Modbus Organization. (2026-07-29, kiegészítve: 2026-07-31) ↩↩↩↩↩↩↩

  4. MODBUS over Serial Line – Specification and Implementation Guide V1.02. Modbus Organization. (2026-07-29) ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩

  5. CODESYS Online Help: Tab „Modbus TCP Client – General” (V4.6.0.0). CODESYS GmbH. (2026-07-29) ↩

  6. CODESYS Online Help: Tab „Modbus TCP Server Device – General” (V4.6.0.0). CODESYS GmbH. (2026-07-29) ↩↩

  7. MODBUS Messaging on TCP/IP Implementation Guide V1.0b. Modbus Organization / Modbus-IDA. (2026-07-31) A 502-es port és az MBAP-fejléc mezői. ↩↩↩↩↩↩

Mennyire volt hasznos ez a fejezet?

Még nincs értékelés.