Energie - Verbrauchs - Auswertung
 
 

Mod-Bus

Grundlagen


Das MODBUS Protokoll wurde in den 70 Jahren von der Firme Modicon (heute Schneider Electric) für die eigene SPS als Geräteprotokoll entwickelt. Mittlerweile wird das Protokoll auch von anderen Herstellern für deren Geräte verwendet, da es sich um ein offenes Protokoll handelt. Durch diese Offenheit ist das Protokoll als de Facto Standard geworden. Master-Slave Verfahren:
Das MODBUS-Protokoll ist ein serielles, Master-Slave Protokoll. Die Kommunikation wird immer vom Master durch eine Abfrage begonnen. Jeder Slave besitzt seine einmalige Adresse. Der Slave dessen Adresse abgerufen wird, reagiert entsprechend auf die Befehle des Masters und liefert die abgefragten Daten zum Master oder führt die vom Master angeforderte Aktion aus. Wenn der Master ein allgemeines Telegramm an alle Slaves versendet, werden keine Antworten von den Slaves an den Master zurück gesandt. Die Slaves können nicht untereinander kommunizieren und können keine Kommunikation mit dem Master beginnen. Bei einer Anfrage des Masters an die Slaves wird auf die Antwort der Slaves gewartet. Sollte der Slave aber nicht in Funktion sein, würde der Master ewig warten. Dieses Problem wird durch die Timeout-Funktion behoben.

Betriebsarten:

Bei der Datenübertragung werden drei verschiedene Betriebsarten unterschieden:
  • MODBUS RTU (Daten werden in binärer Form übertragen, können nicht direkt vom Menschen gelesen werden, guter Datendurchsatz)
  • MODBUS TCP (Übertragung wie bei RTU, allerdings über das TCP/IP- Paket)
  • MODBUS ASCII (Daten werden in ASCII-Code übertragen, können direkt vom Menschen gelesen werden, geringer Datendurchsatz)
Für unser Projekt benutzen wir die MODBUS RTU Implementierung, da der Modbus-Energiezähler nur diese Implementierung unterstützt.


MODBUS RTU (Remote Terminal Unit)-Protokollaufbau

Im RTU-Modus sind die Frames durch 3.5fache Zeichen Übertragungszeit voneinander getrennt. In das Adressfeld wird die Empfängeradresse eingetragen (gültiger Bereich 1-247). Das Adressfeld besteht aus 8 Bit. Der Slave sendet bei seiner Antwort an den Master ebendiese Adresse zurück, damit der Master die Antwort zuordnen kann. Das Funktionsfeld besteht aus 8 Bit. Hat der Slave die Anfrage des Masters korrekt empfangen, so antwortet er mit demselben Funktionscode. Ist ein Fehler aufgetreten, so verändert er den Funktionscode, indem er das höchstwertige Bit des Funktionsfeldes auf 1 setzt. Das Datenfeld enthält Hinweise, welche Register der Slave auslesen soll, und ab welcher Adresse diese beginnen. Der Slave setzt dort die ausgelesenen Daten (z. B. Messwerte) ein, um sie an den Master zu senden. Im Fehlerfall wird dort ein Fehlercode übertragen. Das Feld für die Prüfsumme, die mittels CRC ermittelt wird, beträgt 16 Bit. Das gesamte Telegramm muss in einem kontinuierlichen Datenstrom übertragen werden. Tritt zwischen zwei Zeichen eine Sendeunterbrechung auf, die länger als 1,5 Zeichen ist, so ist das Telegramm als unvollständig zu bewerten und sollte vom Empfänger verworfen werden.

Start  Adresse  Funktion  Daten  CR-Check  Ende 
Wartezeit (min. 3,5 Zeichen)  1 Byte  1 Byte  n Byte  2 Byte  Wartezeit (min 3,5 Zeichen) 

Zuletzt aktualisiert am 02.02.2014