Modbus auslesen – erweiterte Version

Modbus-Parameterliste

• besteht aus mehreren Abschnitten, bitte die mitgelieferte Struktur nutzen und diese nur anpassen oder im gleichen Muster erweitern
• „ModbusParameter“ Abschnitt
  • „unitid“ => nur diese ist hier relevant, es wird die id in der Modbus konfiguration (FlexGetter) damit überschirben
  • die restlichen Objekte dienen nur der besseren Übersicht und werden nicht ausgwertet
• „ModbusCommands“ Abschnitt
  • besteht aus einem oder mehreren Abschnitten (Objekten). Jeder Abschnitt (Objekt) enthält die Grundkonfiguration für die Anfrage an den Modbus Node. Die Beschriftungen sollten eindeutig sein. Das Element „interval“ wird nur ausgewertet wenn man den Modbus-Node „node-red-contrib-modbustcp“ benutzt, sonst nicht
  • „quantity“ => wie viele 16 Bit Register ab „addressStart“ vom Modbus abgefragt werden sollen
• „ModbusAdresses“ Abschnitt
  • besteht aus einer Anzahl von Objekten für jede Information (jedes Register) welches man auslesen möchte
  • es gibt hier eine Definition der Registeradresse (Objektname) und dann einige Eigenschaften welche die Modbus Daten dieses Register genauer beschreiben und unter welchem Namen das Objekt am Ausgang des Subflows „ModbusResponseExtract“ dann publiziert (ausgegeben) wird.
  • genaueres dann in der Beschreibung für diesen Subflow
  • es müssen nicht zwingend alle Modbus Adressen, die abgeholt werden in diesem Abschnitt deklariert sein, Lücken sind kein Problem. Werden zu wenige Register abgeholt (quantity) können die hier angegebenen Register nicht ausgewertet werden, verursachen aber kein wirkliches Problem
  • Sind Registeradressen angegeben die nicht abgerufen werden, so werden diese einfach ignoriert. Im Modus „LogError=true“ werden dazu in der NodeRED Konsole Meldungen ausgegeben sonst merkt man das nicht nur dass halt Werte nicht vorhanden sind.
• „ModbusPermission“ Abschnitt
  • dieser Abschnitt dient nur zur Information und enthält eine mini Beschreibung welche Namen in der Parameterliste erlaubt bzw. berücksichtigt werden

der inject Node bekommt die folgenden Einstellungen:

• topic => beliebig
• payload => hier befindet sich die gesamte „Modbus-Parameterliste“
• einmalig injizieren => anhaken, damit wird bei jeder Änderung automatisch der Flow angestoßen damit die Parameterliste auch in der globalen Variable aktualisiert wird
• Wiederholung => diese Angaben dienen nur der doppelten Absicherung damit bei irgendwelchen Umständen der Nichtverfügbarkeit der Variable diese täglich erstellt wird

Name des Speicherplatz für die „Modbus-Variablenliste“. Genau dieser Name ist in den anderen Subflows in der Parameterliste anzugeben!

• „setze – global“ => in dieses Feld einen String eingeben. Unter diesem Namen wir die globale Variable erzeugt in welcher die „Modbus-Variablenliste“ abgelegt wird. Die restlichen Felder bitte nicht ändern

• den verwendeten Modbus Node „Modbus-Flex-Getter“ aus node-red-contrib-modbus (dieses Modul muss im NodeRED eventuell nachinstalliert werden) die Konfiguration der Modbus TCP Anbindung mit der eigene IP Adresse des entsprechenden Modbus TCP Gerätes versehen und die restlichen Parameter angeben dabei wird die „Unit-id“ im Code durch eine selbst definierte ID ersetzt (oder den modbustcp Node entsprechend parametrieren)
  • der Node sollte nach einer kurzen Initialisierungsphase schon mal „active“ anzeigen
  • Name => beliebig aber lesbar
  • Host => die IP Adresse des Modbus Device
  • Port => normalerweise bleibt es bei 502 (Modbus Device Dokumentation)
  • Unit-id => beliebige Zahl, wird durch den Code ersetzt
  • Timeout => bitte nicht zu kurz ansetzen
  • Reconnect => bitte nicht zu kurz ansetzen
• hat man diesen Node erstmals neu installiert, muss man einen neuen „Server“ anlegen, der dann den Parametersatz für die Modbus-TCP Anbindung enthält.
• der FlexGetter fragt von sich aus keine Modbus Register ab, er muss am Eingang ein Mesage Objekt in einer entsprechenden Struktur erhalten. Dies liefert der „ModbusGetCommand“ Subflow dessen Inhalt sind die konfigurierten Parameter der „Modbus-Parameterliste“

• die Parameter im Node „ModbusGetCommand“
  • Name => beliebig
  • N_ModbusParam => der Name der globalen Variablen in dem die gesamte Modbus-Parameterliste enthalten ist (siehe oben)
  • node-red-contrib-modbus => true wenn der anschließeden Node „node-red-contrib-modbus“ verwendet wird (hier der Abbildung verwendet) ODER false wenn der Node aus „node-red-contrib-modbustcp“ verwendet wird

• die Parameter im Node „ModbusResponseExtract“
  • Name => beliebig
  • N_ModbusParam => der Name der globalen Variablen in dem die gesamte Modbus-Parameterliste enthalten ist (gleich wie oben)
  • ModbusAddrKorr => ein Korrekturfaktor für die Modbus Adressen, warum auch immer nutzen manche Device Adressen die von der Parameterliste um +- 1 bis 2 versetzt sind, hier kann der Korrekturfaktor eingetragen werden. Hat man den richtigen Wert, so kommen auch plausible Werte, liefert die Konvertierung „Müll“ so muss man den Korrekturfaktor anpassen (siehe Beschreibung der Modbus TCP Device Adressliste). Theoretisch kann man auch einfach die Registeradressen anpassen aber mit dieser Einstellung kann man 1 zu 1 die Registeradressen der Modbus Deviceliste nutzen und kann bei Fehlern 1 zu 1 vergleichen.
  • LogError => Fehler Logging Ein-/Ausschalten (zum Fehler suchen)
    • true => Fehler Logging eingeschaltet
    • false => Fehler Logging ausgeschaltet
  • oldPayload => Original Modbus Output mitsenden true/false (zum Fehler suchen)
  • ModbusParam => Abfrage Modbus Parameter mitsenden true/false (zum Fehler suchen)

• die Parameter in einem oder mehreren (Sub-) Node „PayloadMultiToSingle“ beispielhaft für ein Modbus Register „PVLeistung“. Dieser Node wird so konfiguriert dass er aus den ganzen ausgelesenen Modbus Registern und den daraus sich erggebenden Payload Objekten nur dieses spezielle Objekt ermittelt und dessen umgerechneten Wert des Datenpunktes (Messwert) als payload ausgibt und dann noch einige ander wesentliche Objekte beschreibt. Will man also 7 Modbus Register auswerten, muss man 7 Abschnitte in der Modbus-Parameterliste definieren. Für diese 7 Register wird EIN Message Objekt (payload.*) mit 7 Unterobjekten ausgegeben. Jeweils eines davon lässt sich mit diesem Node aus dem Gesamtobjekt „herauslösen“ und vereinzeln
  • Name => beliebig
  • In jedem Parameter ist nur der String zwischen „payload.“ und „.val“ anzupassen, hier im Beispiel das Wort „PVLeistung“. Der richtige Name (Groß-Kleinschreibung beachten) wurde vorher in der Modbus-Parameterliste selbst gewählt. Es ist der identische String der pro Parameter im JSON Objekt bei „msgName“ angegeben wurde. Er sollte so gewählt werden dass man als Mensch noch vestehen kann was genau sich dahinter verbirgt. Bitte keine speziellen Sonderzeichen , Leerzeichen oder ähnliches benutzen!
  • valSource => der Pfad und Name des Objektes dessen Value am Ausgang dieses Nodes in msg.payload stehen soll
    • der String ist etwas davon abhängig wie man die Modbus-Parameterliste definiert hat. Normalerweise „payload.“ + Objektname + „.val“
  • topicSource => der String ist etwas davon abhängig wie man die Modbus-Parameterliste definiert hat. Normalerweise „payload.“ + Objektname + „.nameUser“ (hier muss ich noch etwas in einer nächsten Version verbessern)
  • unitSource => der String ist etwas davon abhängig wie man die Modbus-Parameterliste definiert hat. Normalerweise „payload.“ + Objektname + „.unit“ (die Unit wir 1 zu 1 aus der Modbus-Parameterliste durchgereicht
  • nameSource => der String ist etwas davon abhängig wie man die Modbus-Parameterliste definiert hat. Normalerweise „payload.“ + Objektname + „.nameUser“ (der String wir 1 zu 1 aus der Modbus-Parameterliste durchgereicht, er sollte einen menschenlesbaren Namen in der Parameteriste erhalten

der inject Node „Zeitsteuerung der Abfrage“ dient einzig als zyklischer Trigger zum Anstoßen der Modbus-TCP Abfrage. Das Timing ist dem eigenen Bedarf anzupassen. Bei zu kurzen Abständen und zu vielen Modbus Abfragebereichen und Anzahl der abzufragenden Register können die Modbus Device eventuell nicht mehr richtig funktionieren.

• Wiederholung => in welchem Zyklus alle Modbus Parameter aus der Modbus-Parameterliste abgeholt werden sollen und im Anschluss dann zur Verfügung gstellt werden – Aktualisierungsrate aller Werte

Die Modbus Parameterliste (im inject Node „E3DC – Modbus Parameter“) ist ein JSON Objekt und unterliegt den Restriktionen von JSON. Die Liste ist in 4 grundsätzliche Blöcke unterteilt „ModbusParameter“, „ModbusCommands“, „ModbusAdresses“ und „ModbusPermission“. Davon dient der Abschnitt „ModbusPermission“ nur zur Information und als Hilfe bei der Erstellung / Änderung von Parametern.
ModbusParameter=>Basis Modbus Abfrage
ModbusCommands=> ein oder mehrere Blöcke für die dierekt Modbus Register Abfrage
ModbusAdresses => Definition jedes einzelnen auszuwertenden Modbusregister mit allen Eigenschaften des Datenpunktes und des dann erzeugten NodeRED Message Objektes.
Bitte bei Änderungen beachten: die Kommasetzung und Leerzeichen / Sonderzeichen

• unitid => die Unit ID des Modbus Device (der genaue Wert ist bei Modbus TCP eingentlich unkritisch aber bei mehreren paralelen Modbus Anbindungen könnte das eine Rolle spielen: 0 oder 1 sollten funktionieren)
• ModbusName => beliebig, dient nur zur besseren Lesbarkeit
• ModbusMemo => beliebig, dient nur zur besseren Lesbarkeit
• VersionParameter => beliebig, dient nur zur besseren Übersicht

Besteht aus einem oder mehreren JSON Objekten. Jedes Objekt beschreibt ab welcher Startadresse wie viele Modbus Register Adressen (Anzahl) abgeholt werden sollen, welcher Modbus Funktionscode dafür genutzt wird und legt eine Verzögerung fest damit mehrere Funktionsblöcke nacheinander nicht sofort vom Modbus Device abgeholt werden sollen sondern mit einer verzögerten Anfrage. Man kann also weit auseinander liegende Registerbereiche in Abschnitte unterteilen um nicht in einem Rutsch hunderte Register auslesen zu müssen. Man muss auch nicht zwingend alle abgeholten Register im späteren Flow auswerten.

• Objektname z.B. „Identifikationsblock“ => frei wählbar, hat keine Auswirkung
• addressStart => Startadresse für diesen Block. Ab dieser Registeradresse werden vom Modbus TCP Device die Daten abgeholt.
• quantity => Anzahl der aufeinanderfolgenden Registeradressen die ab „addressStart“ abgeholt werden. (Die einzelnen Registeradressen aus dem Abschnitt „ModbusAdresses“ sollte sich in einem der hier definierten Bereiche befinden)
• „delay_ms“ => enthält einen Zahlenwert in Millisekunden. Um diese Zeitspanne verzögert wird diese Modbus Registerabfrage gestartet. Nutzt man nur einen einzigen Block kann man hier eine 0 eintragen. Nutzt man mehrere Blöcke, so kann der erste Block eine 0 und im nächsten Block sollte man besser „1000“ oder größer angeben. Ich nutze „10000“ also 10 Sekunden, das gibt aktuell keine Probleme.
• „topic“ => frei wählbar – hat aktuell keine weiteren Auwirkungen
• „interval“ => diese Angabe wird nur bei Anwendung des Modbus Node „node-red-contrib-modbustcp“ ausgewertet und verwendet. Es gibt das zyklische Timing an, in welchem Intervall immer wieder dieser Adressbereich abgefragt wird. In der hier beschriebenen aktuellen Konfiguration wird ein anderer Node, der „Modbus-Flex-Gatter“, benutzt, dabei ignoriert der Code diese Angabe.
• „memo“ => frei wählbar, als Gedankenstütze zum Beispiel

Der Abschnitt „ModbusAddresses“ enthält einen oder mehrere Blöcke (Objekte) welche immer eine Modbus Adresse – einen Modbus Datenpunkt – komplett beschreiben. Diese beschreibenden Informationen nutzt der Subflow „ModbusResponseExtract“ und erstellt aus der Modbus Antwort (aus den 16 Bit Registerwerten) von genau dem richtigen Abschnitt der Antwort ein Message Objekt welches alle relevanten Informationen und Umrechnungsdefinitionen des Datenpunktes enthält. Also wird dadurch aus dem 16 Bit Muster z.B. eine Zahl oder ein String.

• Registeradresse als Objektname mit den Elementen der Beschreibung des Datenpunktes – hier im Beispiel „40001“ bedeutet die Modbus Registeradresse 40001. Das Objekt enthält dann alle weiteren Deklarationen für genau diesen Datenpunkt.
• msgName => String, frei definierbar, daraus wird der Name des Message Objektes erzeugt der dann wiederum als (Unter-)Objekt im Payload am Ausgang des „ModbusResponseExtract“ Node ausgegeben wird. Hier keine Sonderzeichen und Leerzeichen benutzen!
• name => String, frei definierbar, es ist vorgesehen hier den Text aus der Modbus Registerbeschreibung des Devices zu hinterlegen damit bei späterer Kontrolle genau klar ist um welchen Parameter es sich handelt.
• „nameUser“ => String, frei definierbar, ein möglichst menschenlesbarer Name für diesen Datenpunkt. Im berechneten Message Objekt wird dieser Name als „topic“ ausgegeben, der dann evtl. zur Beschriftung bei Visuellen Elementen genutzt werden könnte.
• type => String, Datentyp des Modbus Register. Hier sind nur spezielle vordefinierte Strings erlaubt. Diese beschreiben wie der Modbus Datenpunkt in einen realen Wert umgerechnet (konvertiert) werden muss. In der aktuellen Version sind die folgenden Typkonvertierungen umgesetzt: HEX16 UINT16 INT16 UINT32 INT32 STRUINT8.STRUINT8 STRING BITFIELD16 BITFIELD16SWAP FLOAT64. Die Modbus Registerbeschreibung enthält einen Hinweis welche dieser Typkonvertierung angegeben werden soll. Sind für manche Typen mehrere Register nötig, werden automatisch die weiter aufsteigenden Register zur Berechnung mit benutzt.
• unit => String, frei definierbar, ein String zur Beschreibung der Maßeinheit des Datenpunktes. Im berechneten Message Objekt wird dieser String als „unit“ ausgegeben.
• gain => Integer, Manche Datenpunkte benötigen eine Division durch einen Wert um das richtige Ergebnis zu liefern. Dieser Divisor ist hier anzugeben. Beispielhaft für die Spannung der Phase L1 über den Modbus intern als Wert 2325 ausgegeben. Gibt man hier bei „gain“ die 10 ein, so wird der Wert durch 10 dividiert und als Ergebnis wird 232,5 ausgegeben was dem richtigen Spannungswert entspricht. Dieser Faktor kann aus der Modbus Registerbeschreibung entnommen werden.
• quantity => Integer, wird aktuell nur benätigt wenn „type:STRING“ genutzt wird da hier definiert ist wie 16 Bit Werte hintereinander in ASCII Zeichen umgewandet und als String ausgegeben werden sollen. Alles andern Konvertierungen ignorieren diese Angabe.
• memo => beliegbig, was man noch so hinterlegen will

Beispielhaft das Mesage Objekt ‚PVLeistung‘

• payload => Messwert (128 Watt“
• topic => Name (aus der Modbus Parameterliste – „nameUser“)
• unit => Maßeinheit für den Datenpunkt (aus der Modbus Parameterliste – „unit“)
• name => Name (aus der Modbus Parameterliste – „nameUser“ – aktuell identisch zu topic)