SPS als ext. IO / SGready

Hallo Forum,

Nach dem Einstieg und ersten Erfahrungen mit OpenEMS kommen mir immer mehr Ideen das System sinnvoll einzusetzen. Im Betrieb wie privat.
Im Betrieb sehe ich viel Potential Lasten abzuschalten um ein Peak-Shaving zu realisieren. Von der Steuerung unseres E-Auto Ladeparks ganz abgesehen…
Zum Beispiel ließen sich viele Lasten bei uns durch eine einfache Relais-Steuerung regeln. Als dezentralen und günstigen Baustein dazu fällt mit die Siemens LOGO! ein. Mit dieser lassen sich per Modbus einfach und sicher Relais schalten.
Mit OpenEMS und seinen Modbus I/Os sollte dies doch eigentlich kein Problem sein, oder? Hat schon jemand Erfahrungen damit gemacht?

Als weitere Idee dazu fällt mit das Thema SGready ein. Die Schaltzustände dieser Schnittstelle ließen sich über eine Mini-SPS doch auch gut regeln, bzw. abfragen. Oder?

Gruß
Klinki

Hallo Klinki,

freut mich zu hören!

Eine einfache Lastspitzenkappung mit Lastabwurf lässt sich out-of-the-box mit einem (IO Channel-Single-Threshold"-Controller) umsetzen. Dazu als inputChannelAddress die _sum/GridActivePower angeben und in der outputChannelAddress einen Digitalausgang. Als Digitalausgänge sind das WAGO I/O 750-System (openems/io.openems.edge.io.wago at develop · OpenEMS/openems · GitHub) und das KMTronic Modbus Relaisboard (z. B. sowas: https://sigma-shop.com/product/153/rs485-8-channel-relay-controller-modbus-rtu.html; Implementierung: openems/io.openems.edge.io.kmtronic at develop · OpenEMS/openems · GitHub) gut unterstützt. Das individuelle Protokoll einer LOGO! müsste man noch implementieren.

Anders herum würde auch gehen: die LOGO! könnte via Modbus die aktuellen Daten vom OpenEMS auslesen und die Logik für den Lastabwurf umsetzen. Dazu braucht es seitens OpenEMS dann den Modbus-API-Controller. Das Modbus-Protokoll kann über das OpenEMS UI Anlagenprofil heruntergeladen werden. (siehe Untitled :: FENECON Dokumente)

Für die Steuerung einer SG-Ready Wärmepumpe gibt es bereits einen Controller: openems/io.openems.edge.controller.io.heatpump.sgready at develop · OpenEMS/openems · GitHub

Gruß,
Stefan

Moin Stefan,

Vielen Dank für Deine ausführliche Antwort.
Dass die Logo selbst das OpenEMS fragt und einen Lastabwurf vollzieht ist natürlich auch ein Ansatz. Ich persönlich finde es sympathischer die I/Os möglichst “dumm” zu halten und das EMS die Arbeit machen zu lassen. Schon wegen logging.

Hab schon eine Logo bestellt und werde berichten.

Gruß,
Klinki

Moin,

Ich habe den Single Threshold-Controller jetzt konfiguriert. Noch nicht in Verbindung mit meiner Logo, sondern ein eine Mosbus-Slave Software. Der Zustand der Coils wird im Log korrekt angezeigt. Die Kommunikation per Modbus sollte demnach also funktionieren.

Allerdings schaltet der Kontroller nicht. Im Modbus-Log wird zyklisch FC1 (ReadCoils) genutzt. Aber ein Write-Befehl kommt nicht an.

Um den Controller später sinnvoll mit der Logo zu nutzen, müsste ich die Modbus-Register der einzelnen Coils ändern. In KmtronicRelay4PortImpl
habe ich bisher nur ChannelIDs fortlaufend hinzufügen können, also RELAY_5, RELAY_6, usw. Wie man einem Relais aber eine Adresse, z.B. 100, zuordnen kann, ist mir nicht klar.

new FC5WriteCoilTask(0, m(KmtronicRelay4Port.ChannelId.RELAY_5, new CoilElement(4)))

Vielleicht habt ihr einen Tipp für mich…

Gruß,
Klinki

Nachtrag: Ohne am Code noch etwas zu ändern, schaltet der Controller im Modus “Automatic” nun das Relay. Allerdings alle Ausgänge auf einmal und offenbar unabhängig von der GridActivePower - gefühlt random jede Minute ein und aus.

Ich hatte den Controller lediglich entfernt und unter einem anderen Namen wieder neu angelegt.

Den Grund für das Verhalten aus dem letzten Post habe ich nicht finden können und das komplette EMS noch einmal frisch installiert.

Nun habe ich ein neues Modul für die Siemens Logo8 erstellt. Eigentlich nur ein Copy & Paste der bestehenden KMTronic-Module.
Out-of-the-box hat das Gerät einen Standard-Adressbereich für die Ausgangs-Relais. Diesen habe ich als Offset genommen und im Code eingepflegt.

Es funktioniert ganz prima.

Nochmals Danke an Stefan für die Hinweise!

PS: Ich werde mal versuchen nicht die Output-Relais anzusprechen, sondern auch die Inputs zur Verfügung zu stellen. Schließlich kann eine Logo doch mehr leisten als ein einfaches netzwerkfähiges Modbus-Relais

Verwendet man Netzwerkeingänge der Logo, so ist man bei der Wahl der Adressen frei. Somit würde sich das KMTronic-Modul ebenfalls out-of-the-box nutzen lassen. Der Netzwerkeingängen gibt man dem entsprechend die VB-Adresse (virtual byte) 0 und nimmt nur die Bit-Adresse aufsteigend (0-3 oder 0-7).
Somit kann man im Logo-Programm auf die Eingänge reagieren und schaltet nicht “hart” nur die Ausgangs-Relais.
Eine einfache, günstige und flexible Möglichkeit. super!

Hallo Klinki,

super, dass das für dich zufriedenstellend funktioniert hat!

Die Protokolldefinition in OpenEMS ermöglicht, dass immer mehrere Register oder Coils zu einem ReadTask zusammengefasst werden. Es muss dann also nur ein Modbus-Request gesendet werden um mehrere Daten abzurufen.

Am Beispiel des KMTronic 4-Kanal Relaisboards:

https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.io.kmtronic/src/io/openems/edge/io/kmtronic/four/KmtronicRelay4PortImpl.java#L72-L77

  • Hier wird ein Read Coils Task angelegt (Modbus Function Code 1)
  • Die Startadresse des ersten Coils lautet 0
  • Die Priorität der Abfrage ist LOW, das ist hier irrelevant und erst ein Thema, wenn mehrere ReadTasks definiert wurden.
  • Danach kommen dann vier Coils, die jeweils auf einen OpenEMS Channel gemappt werden. Dabei wird dann
    • Coil 0 auf RELAY_1 geschrieben
    • Coil 1 auf RELAY_2 geschrieben
    • Coil 2 auf RELAY_3 geschrieben, und
    • Coil 3 auf RELAY_4 geschrieben

Das OpenEMS Tutorial “Implementing a Device” (Implementing a device :: Open Energy Management System) zeigt ein anderes Beispiel, bei dem ein Function Code 3 Read Registers Task definiert wird, der ab Adresse 1000 startet. Weitere Beispiele für deutlich komplexere Modbus-Protokolle finden sich an vielen Stellen im Code, z. B. hier: https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.goodwe/src/io/openems/edge/goodwe/common/AbstractGoodWe.java#L81

Viele Grüße,
Stefan