Einführung
Wenn Sie nur einen Hammer als Werkzeug haben, ähnelt jedes Problem einem Nagel.
Abraham Maslow
Das Modbus-Protokoll ist sowohl Habr-Lesern als auch Hicktime-Lesern bekannt. Viele Veröffentlichungen haben sich seiner Anwendung gewidmet, die schwer aufzulisten sind, weil es so viele davon gibt, und von Zeit zu Zeit erscheinen hier und da neue Artikel.
Die Popularität dieses Protokolls beruht auf seiner Offenheit und Einfachheit. Der Anwendungsbereich ist breit genug: von professionellen industriellen Automatisierungssystemen bis hin zu Amateur-DIY-Projekten mit verteilten Steuerungssystemen, "intelligenten" Häusern und so weiter. Dieses Protokoll wurde auch von mir gewählt, als mein Team mit der Erstellung von Software für den Zugsimulator beschäftigt war. Das Modbus RTU-Protokoll auf der physischen RS485-Schnittstelle wird in diesem Simulator verwendet, um Daten von Steuerungen, die an der Fahrerkonsole angebracht sind, in den Steuercomputer einzugeben (denken Sie nicht, dass Modbus für echtes rollendes Material verwendet wird!).
Es lohnt sich nicht, über die Schwierigkeiten beim Einrichten von Software zu sprechen, die mit einem Netzwerk von Controllern interagiert, die Geräte steuern. Insbesondere wenn ein Teil der Geräte bereits im Eisen vorhanden ist und der andere Teil sich in der Entwicklung und Herstellung befindet. In diesem Fall muss Software der obersten Ebene unter Berücksichtigung ihrer Interaktion mit dieser Hardware geschrieben werden. Und es ist ratsam, es so zu schreiben, dass sofort eine funktionierende Version des Systems erstellt wird, ohne dass „Krücken“ verwendet werden, die immer schwer vom Code zu entfernen sind.
"Sie müssen Software schreiben, wenn Prototypen der gesamten Hardware fertig sind", sagen Sie, und Sie werden Recht haben, aber ... ha ha ha, das passiert in der realen Welt selten. Und hier helfen uns Software-Emulatoren.
1. Kurz über Modbus RTU
Ich werde nicht im Detail über das Protokoll sprechen. Wer sich für Details interessiert, kann die Suche nutzen - das Protokoll ist offen, seine offizielle Spezifikation und viele Informationen sind im Netzwerk verfügbar. Ich kann nur sagen, dass es in Modbus RTU das Binärformat der übertragenen Daten beschreibt und das RS485-Standard-Twisted-Pair-Kabel als Übertragungsmedium verwendet. RS232 kann auch verwendet werden, wenn das Netzwerk einen Sender und einen Empfänger hat, oder RS422 für die unidirektionale Datenübertragung.
Wir werden an RS485 interessiert sein, einer Halbduplex-Schnittstelle, über die jeweils nur ein Gerät Daten überträgt. Die Arbitrierung des Busses in Modbus erfolgt aufgrund der Dauerhaftigkeit des obligatorischen Ruheintervalls von 3,5 Zeichen bei einer bestimmten Übertragungsgeschwindigkeit. Jede Nachricht sollte mit einem Ruheintervall beginnen und enden. Es gibt ein Master-Gerät im Netzwerk und mehrere Slaves (bis zu 31 in einem Netzwerksegment ohne Verwendung von Repeatern). Jedes Slave-Gerät verfügt über eine eindeutige ID (1 bis 31). Die Datenübertragung durch Slaves erfolgt nur, wenn der Master eine Anforderung zum Empfangen von Daten von diesem Gerät gesendet hat.
Eine typische Assistentenanforderung sieht folgendermaßen aus
| ID | Funktionscode | Datenadresse | Datenmenge (2 Bytes) | Daten | CRC16 |
CRC16 wird verwendet, um die Integrität der übertragenen Daten zu steuern. Modus verwendet die Big Endian-Datendarstellungsnotation: Bei Werten von 2 Bytes steht das höchstwertige Byte in der Nachricht an erster Stelle. Das Protokoll verwendet vier Arten von Daten:
- Spulen - diskrete Ausgänge (1 Bit) zum Lesen / Schreiben
- Digitaleingänge - Nur-Lese-Digitaleingänge (1 Bit)
- Halteregister - Ausgangsregister (2 Bytes) zum Lesen / Schreiben verfügbar
- Eingangsregister - Eingangsregister (2 Bytes) zum Lesen verfügbar
Als Antwort auf die Anfrage sendet der Slave Daten im folgenden Format
| ID | Funktionscode | Die Datenmenge in Bytes | Daten | CRC16 |
Eine vom Master empfangene Nachricht wird in den Empfangspuffer aller Geräte eingegeben. Wenn jedoch das erste Byte des Empfangspuffers nicht mit der Geräte-ID übereinstimmt, werden die empfangenen Daten ignoriert und der Empfangspuffer gelöscht. Wenn die Nachricht für dieses Gerät bestimmt ist, bildet sie eine Antwort und sendet sie nach Einhaltung des Ruheintervalls an den Master.
Wie sie sagen, einfach, aber mit Geschmack. Weitere Informationen hierzu finden Sie in der
offiziellen Protokollspezifikation .
Lesen Sie hier , wie Sie das Protokoll auf der seriellen Schnittstelle implementieren können. Dafür haben wir uns hier nicht versammelt.
Bei der Entwicklung von Top-Level-Software (z. B. auf Basis eines PCs implementierter Master) für ein solches Netzwerk wäre es schön, eine Reihe von Softwaretools zu haben, mit denen ein solches Konzept implementiert werden kann
Die Bedeutung dieses Schemas ist wie folgt. Angenommen, wir haben einen Teil der Geräte im zukünftigen Netzwerk. Oder solche Geräte gibt es bisher nicht. Es besteht jedoch der brennende Wunsch, Software für die oberste Verwaltungsebene zu schreiben und zu debuggen, damit wir nichts neu schreiben müssen, wenn das Netzwerk noch in Hardware implementiert ist. Dazu müssen Sie ein physisches Übertragungsmedium verwenden, für das wir ein ähnliches Gerät verwenden
Einer der Adapter wird verwendet, um die Software des entwickelten Assistenten zu verbinden. Eine andere dient zum Anschließen eines Emulators eines zukünftigen Netzwerks von Slaves. Mit dem Zweig mit einem weißen Anschluss verbinden wir den Teil des Netzwerks, der bereits in Hardware implementiert ist. So haben wir die Möglichkeit, ruhig mit dem Standard-Kommunikationsprotokoll zu arbeiten und schrittweise echte Geräte in Betrieb zu nehmen. Wenn wir dem Kunden das Objekt geben, wird uns nicht die Möglichkeit genommen, seine Software in einer komfortablen Laborumgebung ohne Zugriff auf das Objekt zu ändern. QSlave im Diagramm ist genau derselbe Teil des Netzwerks, der von der Software emuliert wird. Natürlich müssen Sie die entsprechende Software schreiben, die vom Autor erstellt wurde.
2. QSlave - Slave-Netzwerkemulation
QSlave ist ein offener plattformübergreifender Modbus-RTU-Netzwerkemulator. Sie können es unter der GPL v2.0-Lizenz auf Github unter dem obigen Link erhalten.
Die Anwendung wird in C ++ unter Verwendung des Qt-Frameworks entwickelt. Qt verfügt im Allgemeinen
über Bibliotheken für die Arbeit mit Modbus , aber die Besonderheiten der Aufgabe - die Simulation eines Netzwerks von Slaves anstelle eines einzelnen Slaves - führten dazu, dass die integrierten Qt-Bibliotheken für Modbus hier nicht verwendet wurden. Um die von der virtuellen seriellen Schnittstelle empfangenen Daten zu verarbeiten, wurde eine selbstgeschriebene Modbus-Bibliothek erstellt. Der Code dieser Bibliothek wird als separates Projekt implementiert, ist völlig unabhängig von der Benutzeroberfläche und kann zur Kenntnisnahme von Softwaresimulationen mit erweiterten Funktionen verwendet werden. Aufgrund der Tatsache, dass die Modbus-Emulation von der Benutzeroberfläche getrennt ist, wird das Netzwerk mithilfe von Konfigurationsdateien konfiguriert. Das XML-Format wurde gewählt (wir verwenden es häufig in unseren Projekten). Eine Beispielkonfiguration finden Sie
im Projektcode . Eine Reihe von Konfigurationen besteht aus einer Hauptdatei mit der Erweiterung * .net, die so aussieht
example.net<?xml version="1.0" encoding="UTF-8" ?> <Config> <Slave> <Description>Traffic light</Description> <id>1</id> <config>traffic-light</config> </Slave> </Config>
und XML-Konfigurationsdateien für jeden der Slaves
Ampel.xml <?xml version="1.0" encoding="UTF-8" ?> <Config> <Coil> <address>16</address> <description>Red signal</description> <value>0</value> </Coil> <Coil> <address>17</address> <description>Yellow signal</description> <value>0</value> </Coil> <Coil> <address>18</address> <description>Green signal</description> <value>0</value> </Coil> <DiscreteInput> <address>0</address> <description>Ready</description> <value>1</value> </DiscreteInput> <HoldingRegister> <address>5</address> <description>Signal activity time</description> <value>15</value> </HoldingRegister> <InputRegister> <address>2</address> <description>Signals count</description> <value>3</value> </InputRegister> </Config>
Die letzte Datei enthält eine Beschreibung aller auf dem Gerät verfügbaren Daten. Um die Konfiguration herunterzuladen, müssen Sie die * .net-Datei über das QSlave-Programmmenü (Datei → Konfiguration öffnen) öffnen. Alle Konfigurationsdateien müssen sich im selben Verzeichnis befinden. Die Beispielkonfiguration beschreibt ein Netzwerk von einem Slave-Gerät, eine virtuelle Ampel, deren diskrete Ausgänge die Signale beschreiben, ein digitaler Eingang zeigt ein Bit des betriebsbereiten Geräts an (bereit), das Eingangsregister meldet die Anzahl der Ampeln und das Ausgangsregister legt die Zeit fest, während der es eingeschaltet ist jedes der Signale.
Natürlich simuliert dieser Simulator nicht die interne Logik des Geräts. Sie können nur die Werte der Speicherzellen festlegen, die dem Master zur Verfügung stehen. Jeder der Werte kann nach eigenem Ermessen festgelegt werden, indem die entsprechende Zelle in der Tabelle bearbeitet wird.
Bei aller Einfachheit hilft uns diese Software bei der Arbeit an der Simulatorsoftware (die bereits in Betrieb genommen wurde), ohne das Labor zu verlassen.
Niemand sagt jedoch, dass Sie keinen erweiterten Emulator erstellen können, der den Betrieb virtueller Netzwerkgeräte simuliert. Zum Erstellen können Sie den im QSlave-Paket verfügbaren Modbus-Bibliothekscode verwenden.
3. QMaster - Emulation des Master-Geräts
Um Slaves zu erstellen und ihre Firmware zu debuggen, benötigen Sie eine Assistentensimulation. Es gibt eine Reihe offener Emulatoren, wie zum Beispiel
QModbus . Wir haben es in unserer Arbeit verwendet, bis wir beschlossen, die Datenübertragungsrate auf 250 kBit / s zu erhöhen. QModbus erlaubt dies nicht. Es war möglich, es aus den Quellen für Linux neu zu erstellen, aber unsere Elektronikingenieure sitzen unter Windows und wo die Montage aus mehreren Gründen nicht stattfand. Es stellte sich heraus, dass diese Anwendung in Qt 4 geschrieben ist und eine libmodbus-Bibliothek eines Drittanbieters verwendet. Ich wollte eine plattformübergreifende Lösung für Qt5, zumal Qt5 bereits sofort mit Modbus funktioniert. Daher wurde das Analogon mit dem Qt Modbus-Bibliotheksstapel
QMaster geschrieben . Unter den gleichen Bedingungen ist es auch auf Github erhältlich.
Fazit
Abschließend möchte ich sagen, dass ich (bei der Arbeit) hauptsächlich an geschlossenen Projekten arbeite. Die beschriebenen Tools wurden jedoch von mir in meiner Freizeit auf eigene Initiative persönlich entwickelt. Außerdem sind sie in der Windows-Version statisch mit dem Qt-GPL-Code verknüpft, sodass ich sie unter den gleichen Bedingungen wie Qt an die Community weitergeben muss. Darüber hinaus können diese Tools für den Leser nützlich sein.
Vielen Dank für Ihre Aufmerksamkeit!