A Modbus kommunikációs protokoll üzeneteinek teljes körű elemzése

1. A Modbus protokoll fő áttekintése

Modbus énEgy tipikus master-slave architektúrájú kommunikációs protokoll. A master utasításokat kezdeményez, a slave pedig válaszol az adatokra az eszközök közötti olvasási és írási interakció megvalósításához. A protokoll főként három gyakran használt módra oszlik: Modbus RTU, Modbus ASCII és Modbus TCP. Ezek közül az RTU mód nagy átviteli hatékonysággal rendelkezik és kevesebb bájtot foglal el, így az ipari berendezések, intelligens eszközök és soros kommunikáció fő módjaként szolgál. Az ASCII mód jobb olvashatósággal rendelkezik, és főként hibakeresésre és tanulásra használják. A TCP mód az Ethernetre támaszkodik, és alkalmazkodik a távoli hálózati adatgyűjtési forgatókönyvekhez.

Mindennek a magja Modbus kommunikáció az „üzenet”. Az eszközök közötti összes adatolvasás, paraméterírás és állapotlekérdezés lényegében üzenetek küldése, továbbítása és elemzése. A szabványos Modbus üzenetek egységesen négy szegmensből álló struktúrát követnek: slave cím, funkciókód, adatmező és ellenőrző kód.

2. A standard Modbus üzenetkeret-struktúra szétszerelése

Egy teljes Modbus-RTU Az üzenet 4 fix bájthosszúságú és egyértelmű munkamegosztású fő mezőből áll. A szabványos üzenetkeret-struktúrát az alábbiakban mutatjuk be a gyors lekérdezés és a gyakorlati alkalmazás érdekében:

A teljes Modbus üzenet rögzített logikai struktúrával rendelkezik, egyértelműen elkülönített mezőkkel, ami az üzenetelemzés alapja.

2.1 slave cím (1 bájt)

A buszon lévő különböző eszközök megkülönböztetésére szolgál, 0-255 címtartományú, a terepi eszközökben pedig általában 1-247 közötti érvényes címeket használnak. A master pontosan meghatározza a kommunikációs eszközöket címek segítségével, hogy elkerülje a többeszközös kommunikációs konfliktusokat, ami a többeszközös hálózati kommunikáció alapja.

2.2Funkciókód (1 bájt)

Ez határozza meg a kommunikációs művelet típusát, és kulcsfontosságú azonosító az üzenetelemzéshez. Az ipari forgatókönyvekben gyakran használt alapvető funkciókódok a következők: 01 a tekercs állapotának kiolvasásához, 02 a diszkrét bemenetek kiolvasásához, 03 a tartóregiszterek kiolvasásához, 04 a bemeneti regiszterek kiolvasásához, 06 egyetlen regiszter írásához és 10 a regiszterek kötegelt írásához. A különböző funkciókódok különböző adatformátumoknak és elemzési szabályoknak felelnek meg.

2.3 Adatmező (változó hosszúságú)

Az adatmező hosszát a funkciókód határozza meg, beleértve a kezdő regiszter címét, az olvasási/írási mennyiséget és a konkrét adattartalmat. A kérésüzenet tájékoztatja a slave-t a működési pozícióról és tartományról, míg a válaszüzenet valós idejű eszközadatokat vagy végrehajtási eredményeket ad vissza.

2.4Ellenőrzőkód (2 bájt)

Az adatátvitel integritásának ellenőrzésére szolgál. Az RTU mód CRC16 ellenőrzést, az ASCII mód pedig LRC ellenőrzést alkalmaz. Pontosan képes azonosítani a csomagvesztést, az interferenciát, az adattorzítást és az átvitel során fellépő egyéb problémákat, biztosítva az ipari kommunikáció stabilitását.

3. A fő kommunikációs mód üzeneteinek különbségeinek elemzése

A három főáramú Modbus kommunikáció Az üzemmódok alkalmazkodnak a különböző ipari vezérlési forgatókönyvekhez, nagy eltérésekkel az üzenetstruktúrában, a kódolási módban és az ellenőrzési szabályokban. Az alapvető különbségeket az alábbi táblázat tartalmazza a könnyű kiválasztás és megkülönböztetés érdekében:

3.1 Modbus RTU (ipari mainstream)

Az RTU bináris kódolást alkalmaz kompakt keretszerkezettel és redundáns karakterek nélküli magas átviteli hatékonysággal. Ez az RS485/232 soros eszközök alapértelmezett kommunikációs módja. Az üzenetek kezdetét és végét a keretidő alapján ítéli meg, és CRC16 ellenőrzéssel biztosítja az adatok pontosságát, alkalmazkodva a legtöbb intelligens műszerhez és ipari vezérlőberendezéshez.

3.2 Modbus ASCII (hibakeresési preferencia)

ASCII karakterkódolást alkalmaz, az üzenetek kettősponttal ":" kezdődnek, és kocsivissza, illetve soremelés karakterekkel végződnek, így kiváló karakterláthatóságot és alacsony manuális elemzési nehézségeket biztosít. Ugyanakkor nagy átviteli redundanciával és alacsony hatékonysággal rendelkezik, csak tanulási, hibakeresési és hibaelemzési forgatókönyvekhez alkalmas, és ritkán használják tömeggyártású berendezésekben.

3.3 Modbus TCP (hálózati kommunikáció)

Ethernet átvitel alapján egy MBAP üzenetfejlécet ad hozzá az eredeti RTU üzenethez, beleértve a tranzakcióazonosítót, a protokollazonosítót, az üzenet hosszát és egyéb információkat, CRC-ellenőrzés nélkül. Alkalmazkodik a távoli és hálózatközi szegmenseken átívelő ipari IoT adatgyűjtési forgatókönyvekhez.

4. Gyakori függvénykód-üzenetek elemzési példái

A Modbus ipari hibakereséshez gyakran használt funkciókódok rögzítve vannak. A gyakori funkciókódokat és leírásaikat az alábbiakban a gyakorlati működés, a memória és az alkalmazás szempontjából csoportosítottuk:

A leggyakrabban használt 03-as funkciókód (Tartóregiszterek olvasása) példáján alapulva a teljes üzenetelemzési logikát visszaállítjuk, hogy illeszkedjen a helyszíni gyakorlati forgatókönyvekhez.

Master kérésüzenet összetétele: Slave cím + 03 funkciókód + Kezdő regiszter címe + Olvasó regiszterek száma + CRC ellenőrzés.

Normál slave válaszüzenet összetétele: Slave cím + 03 funkciókód + adathossz + regiszteradat + CRC ellenőrzés.

Berendezéskivételek esetén a slave egy rendellenes válaszüzenetet ad vissza, amelynek funkciókódja automatikusan 0x80-nal növekszik, és egy kivételkódot is tartalmaz a gyors hibakereséshez. A gyors hibaelhárításhoz használt gyakori kivételkód-értelmezések a következők:

5. Gyakori üzenetek, hibák és hibaelhárítási módszerek

A tényleges mérnöki hibakeresés során a legtöbb Modbus kommunikációs rendellenesség gyorsan beazonosítható az üzenetelemzés segítségével. A leggyakoribb problémák a következők:

5.1 Kommunikációs időtúllépés:

Leginkább a helytelen slave cím, a kábelezési hibák, az eltérő baud ráta/paritás bitek okozzák, ami a berendezés válaszidejének hiányát eredményezi;

5.2 Adatcsalás:

CRC-ellenőrzési hiba, átviteli interferencia vagy üzenetcsonkítás okozta; ellenőrizze a vonalárnyékolást és a kommunikációs paraméterek konzisztenciáját;

5.3 Kivételkód visszatérése:

A megfelelő kivételkódnak megfelelően hibaelhárítást végez a regisztercím-tartomány, az eszközfunkció-támogatás és az adatírási engedélyek tekintetében;

5.4 Kötegelt adatcsomag-vesztés:

Leginkább a túlzott regiszterolvasási mennyiség és a túl hosszú üzenethossz okozza; az adatokat szegmensekben kell olvasni.

6. Összefoglalás: Az üzenetelemzés mérnöki értéke

A Modbus protokoll lényege a szabványosított üzenet-interakció. Az üzenetkeret-szerkezet, a függvénykódok jelentése, az ellenőrzési szabályok és a kivételkezelési logika ismerete elengedhetetlen képesség az ipari vezérlés hibakereséséhez, a műszerdokkoláshoz és az IoT-gyűjtemények fejlesztéséhez. A pontos üzenetelemzés gyorsan megoldhatja a berendezések kommunikációs hibáit, javíthatja az adatgyűjtés stabilitását, csökkentheti a helyszíni hibakeresési költségeket, és széles körben alkalmazható teljesítménymérőknél, ipari vezérlésnél, épületautomatizálásnál, új energiaberendezéseknél és más ipari forgatókönyveknél.