Das Modbus-TCP Interface des UMD96EL bildet alle Prozessdaten als Fließpunktzahlen in Input-Registern paarweise beziehungsweise in 4er-Gruppen ab. (Bild: PQ Plus)
Da bei den UMD-Messgeräten in der Regel keine steuerungsrelevanten Echtzeitdaten erzeugt werden, ist eine konventionelle Kommunikation ausreichend. Deswegen kann auf verteuernde Zusätze verzichtet werden. Die Daten werden in Datenbausteine direkt eingetragen.
Das Modbus-TCP Interface des UMD96EL bildet alle Prozessdaten als Fließpunktzahlen (32 oder 64 Bit) in Input-Registern paarweise beziehungsweise in 4er-Gruppen ab. Die Konfigurationsdaten werden in Holding-Register abgebildet.
S7-Programm
FB1 (aus dem allgemeinen Modbus-TCP-Beispiel) dient als Modbus-TCP client Treiberbaustein und nutzt die Systembausteine zum Senden und Empfangen über TCP/IP und bleibt unverändert. Als Parameter werden VerbindungsID-Nummer, Knotennummer (UID), Modbus- Kommando (function code 1, 2, 3, 4, 6, 15 oder 16) und Nutzdatenpointer übergeben. Alle lokalen Variablen des Kommunikationstreiberbausteins FB1 sowie Sende- und Empfangsdaten liegen in dem zugehörigen Instanzdatenbaustein. FC1 stellt die Modbus-Kundenapplikation dar und wurde wie folgt angepasst:
Da die relevanten Prozessdaten verstreut liegen, erfolgen mehrere Kommunikationszyklen auf Datengruppen. Im NW3 wird (einmalig nach dem Hochlauf) die Konfiguration über function code 10hex geschrieben. Im NW4 werden Statusregister gelesen, in NW5 die Spannungswerte L1-L3, im NW6 die Stromwerte L1-LN, in NM7 die Leistungsfaktoren, in NW8 die Wirk- und Scheinleistungen und in NW9 die Energiezähler. In NW10 wird der Sprungverteiler auf 1 zurückgesetzt, um den Reset-State nicht zyklisch auszuführen. Der Setup-State wird über Bit M 96.0 verriegelt und kann bei Bedarf aktiviert werden. hei
