Volledige analyse van Modbus-communicatieprotocolberichten

1. Kernoverzicht van het Modbus-protocol

Modbus iModbus is een typisch master-slave communicatieprotocol. De master initieert instructies en de slave reageert op data om lees- en schrijfinteractie tussen apparaten mogelijk te maken. Het protocol is hoofdzakelijk onderverdeeld in drie veelgebruikte modi: Modbus RTU, Modbus ASCII en Modbus TCP. De RTU-modus heeft een hoge transmissie-efficiëntie en gebruikt minder bytes, waardoor het de meest gebruikte modus is voor industriële apparatuur, intelligente instrumenten en seriële communicatie. De ASCII-modus is beter leesbaar en wordt vooral gebruikt voor debugging en training. De TCP-modus maakt gebruik van Ethernet en is geschikt voor scenario's met gegevensverzameling op afstand via een netwerk.

De belangrijkste drager van alles Modbus-communicatie "Message" is een term die in feite verwijst naar het verzenden, verzenden en analyseren van berichten. Alle data-leesbewerkingen, parameter-schrijfbewerkingen en statusopvragingen tussen apparaten komen neer op het verzenden, doorgeven en analyseren van berichten. Standaard Modbus-berichten volgen een uniforme structuur van vier segmenten: slave-adres, functiecode, dataveld en controlecode.

2. Demontage van de standaard Modbus-berichtframe-structuur

Een complete Modbus-RTU Een bericht bestaat uit 4 kernvelden met vaste byte-lengtes en een duidelijke taakverdeling. De standaard berichtstructuur is hieronder weergegeven voor snelle raadpleging en praktische toepassing:

Het complete Modbus-bericht heeft een vaste logische structuur met duidelijk afgebakende velden, wat de basis vormt voor berichtanalyse.

2.1 Slave-adres (1 byte)

Het wordt gebruikt om verschillende apparaten op de bus te onderscheiden, met een adresbereik van 0-255, waarbij 1-247 veelgebruikte geldige adressen zijn voor veldapparaten. De master specificeert communicatieapparaten nauwkeurig via adressen om conflicten in de communicatie tussen meerdere apparaten te voorkomen, wat de basis vormt voor netwerkcommunicatie tussen meerdere apparaten.

2.2 Functiecode (1 byte)

Het bepaalt het type communicatiebewerking en is een belangrijke identificator voor berichtanalyse. Veelgebruikte kernfunctiecodes in industriële scenario's zijn onder andere: 01 voor het uitlezen van de spoelstatus, 02 voor het uitlezen van discrete ingangen, 03 voor het uitlezen van holdingregisters, 04 voor het uitlezen van ingangsregisters, 06 voor het schrijven naar een enkel register en 10 voor het in batches schrijven naar registers. Verschillende functiecodes corresponderen met verschillende dataformaten en analyseregels.

2.3 Gegevensveld (variabele lengte)

De lengte van het dataveld wordt bepaald door de functiecode, inclusief het adres van het startregister, de lees-/schrijfhoeveelheid en de specifieke data-inhoud. Het verzoekbericht informeert de slave over de positie en het bereik van de bewerking, terwijl het antwoordbericht realtime apparaatgegevens of uitvoeringsresultaten retourneert.

2.4Controlecode (2 bytes)

Het wordt gebruikt om de integriteit van de gegevensoverdracht te controleren. De RTU-modus gebruikt een CRC16-controle en de ASCII-modus een LRC-controle. Het kan pakketverlies, interferentie, gegevensvervorming en andere problemen tijdens de transmissie nauwkeurig identificeren, waardoor de stabiliteit van industriële communicatie wordt gewaarborgd.

3. Analyse van verschillen in boodschappen in gangbare communicatiemethoden

De drie belangrijkste Modbus-communicatie De modi passen zich aan verschillende industriële besturingsscenario's aan, met grote verschillen in berichtstructuur, coderingsmodus en controleregels. De belangrijkste verschillen zijn voor eenvoudige selectie en onderscheid in de onderstaande tabel weergegeven:

3.1 Modbus RTU (Industriële hoofdstroom)

RTU maakt gebruik van binaire codering met een compacte framestructuur en een hoge transmissie-efficiëntie zonder redundante tekens. Het is de standaard communicatiemodus voor RS485/232 seriële apparaten. Het bepaalt het begin en einde van berichten aan de hand van de frame-intervaltijd en garandeert de nauwkeurigheid van de gegevens via een CRC16-controle, waardoor het geschikt is voor de meeste intelligente instrumenten en industriële besturingsapparatuur.

3.2 Modbus ASCII (Foutopsporingsvoorkeur)

Het maakt gebruik van ASCII-tekencodering, waarbij berichten beginnen met een dubbele punt ":" en eindigen met een regelterugloop en regeleinde. Dit resulteert in een hoge leesbaarheid van de tekens en een lage moeilijkheidsgraad bij handmatige analyse. Het kent echter een grote transmissieredundantie en een lage efficiëntie, waardoor het alleen geschikt is voor leer-, debug- en foutanalysescenario's en zelden wordt gebruikt in massaproductieapparatuur.

3.3 Modbus TCP (netwerkcommunicatie)

Gebaseerd op Ethernet-transmissie, voegt het een MBAP-berichtheader toe aan het originele RTU-bericht, inclusief transactie-ID, protocol-ID, berichtlengte en andere informatie, zonder CRC-controle. Het is geschikt voor dataverzamelingsscenario's voor industriële IoT-toepassingen op afstand en over verschillende netwerksegmenten heen.

4. Analysevoorbeelden van veelvoorkomende functiecodeberichten

De meest gebruikte functiecodes voor Modbus-debugging in industriële omgevingen zijn vastgelegd. De meest voorkomende functiecodes en hun beschrijvingen zijn hieronder gesorteerd voor praktisch gebruik, geheugen en toepassing:

Aan de hand van de meest gebruikte functiecode 03 (Lezen van wachtregisters) als voorbeeld, wordt de volledige berichtanalyse-logica aangepast aan de praktijksituaties op locatie.

Samenstelling van het masterverzoekbericht: Slave-adres + 03-functiecode + Startregisteradres + Aantal leesregisters + CRC-controle.

Normale samenstelling van een slave-antwoordbericht: Slave-adres + 03-functiecode + Gegevenslengte + Registergegevens + CRC-controle.

In geval van apparatuurafwijkingen stuurt de slave een abnormaal antwoordbericht terug, waarbij de functiecode automatisch met 0x80 wordt verhoogd en vergezeld gaat van een uitzonderingscode voor snelle foutopsporing. De meest voorkomende interpretaties van uitzonderingscodes voor snelle foutopsporing zijn als volgt gerangschikt:

5. Veelvoorkomende berichtfouten en methoden voor probleemoplossing

Bij daadwerkelijke technische foutopsporing kunnen de meeste afwijkingen in Modbus-communicatie snel worden opgespoord door middel van berichtanalyse. De meest voorkomende problemen zijn als volgt:

5.1 Communicatietime-out:

Meestal veroorzaakt door een onjuist slave-adres, bedradingsfouten, niet-overeenkomende baudrate/pariteitsbits, waardoor de apparatuur niet reageert;

5.2 Gegevensvervorming:

Veroorzaakt door een fout in de CRC-controle, transmissiestoringen of afkapping van berichten; controleer de afscherming van de lijn en de consistentie van de communicatieparameters;

5.3 Retourcode uitzondering:

Los problemen met het adresbereik van het register, de ondersteuning van apparatuurfuncties en de schrijfrechten voor gegevens op aan de hand van de bijbehorende uitzonderingscode;

5.4 Verlies van batchdatapakketten:

Meestal veroorzaakt door een te grote hoeveelheid registerlezingen en te lange berichten; gegevens moeten in segmenten worden gelezen.

6. Samenvatting: De technische waarde van berichtanalyse

De essentie van het Modbus-protocol is de gestandaardiseerde uitwisseling van berichten. Kennis van de structuur van berichtframes, de betekenis van functiecodes, controleregels en foutafhandeling is essentieel voor het debuggen van industriële besturingen, het koppelen van instrumenten en de ontwikkeling van IoT-gegevensverzameling. Nauwkeurige berichtanalyse kan snel communicatiestoringen in apparatuur oplossen, de stabiliteit van gegevensverzameling verbeteren, de kosten voor debugging op locatie verlagen en is breed toepasbaar in energiemeters, industriële besturing, gebouwautomatisering, apparatuur voor nieuwe energiebronnen en andere industriële scenario's.