Wago /SPS über Modbus(TCP/IP) in FHEM steuern

[ChrisD]

Hallo,

So könntest du den Slider mit dem Modbus verbinden:

Code Auswählen Erweitern

define sl_10 dummy
attr sl_10 setList state:slider,10,1,30
attr sl_10 webCmd state
define n_sl_10 notify sl_10:.* {write_modbus(10,$EVENT)}


Wenn ein Element aus FHEM Daten auf den Modbus schreiben soll musst du dies mit einem notify machen. Das Lesen von Daten muss zyklisch über at gemacht werden.

Grüße,

ChrisD

[leibi]

Hallo,

danke genau das hat mir gefehlt, $Event ist eigentlich SPS mässig gesehen, die Übergabe-Variable.

gruß
Markus

[leibi]

Hallo,

kann ich Event auch verwenden, wenn ich ein Log, der "Modbus_Temperatur" erstellen will?

MFG
Markus

[ChrisD]

Hallo,

Im Beispiel mit dem Slider enthält $EVENT die ausgewählte Zahl, bei anderen Geräten musst du teilweise $EVTPARTx verwenden. Details dazu gibt es in der CommandRef.

Zum Loggen brauchst du nur ein FileLog zu definieren, $EVENT ist hierbei nicht nötig. Gelesene Daten kannst du, wenn Modbus_Temperatur ein Dummy ist welches über modbus_Read_Zaehler gesetzt wird, z.B. so in ein Filelog bekommen :

Code Auswählen Erweitern

define FL_Modbus_Temperatur FileLog ./log/Log_Modbus_Temperatur-%Y%m.log Modbus_Temperatur

Wichtig ist hierbei der letzte Teil (Modbus_Temperatur), dieser legt fest was geloggt werden soll, Details gibt es auch hier in der CommandRef. Bei jedem Setzen von Modbus_Temperatur über at wird ein Wert in der Logdatei abgspeichert. Wenn du nur Werte bei Änderung speichern möchtest musst du das Attribut event-on-change-reading bei Modbus_Temperatur verwenden.

Grüße,

ChrisD

[oniT]

Hi ChrisD,

seitdem ich die 99_modbus.pm einsetze, habe ich keine disconnects vom HMLan mehr. Mit der Abfrage welche ich zuvor nutzte war dies ständig der Fall. Da ich nun nicht ganz so der Perl Spezi bin hätte ich dazu eine Frage, ob man dieses Modul nicht erweitern kann und die darin bereits eingetragene IP Adresse auslagern könnte und in den Code in die fhem.cfg einfügen kann. Wie man es zum Beispiel mit dem Modul vom Solarview macht. Dies hätte den Vorteil, dass man die 99_modbus.pm für weitere angeschlossene Geräte verwenden könnte.

Danke
Gruß,
Tino

[lechez]

Hallo ChrisD,

ja man kann die IP adresse Port etc. auslagern und dies einbinden. Ich habe das Modul 99_Modbus.pm "quick and dirty" geschrieben, da noch nichts vorhanden war und es erstmal für mich gemacht habe. Da es so aussieht, dass die Nachfrage groß ist. Man kann dazu übergehen das Modul mal "sauber" zu machen. Auch ein Wiki wäre ja nicht schlecht oder?
Vielleicht komme ich noch dazu.

Gruß

lechez. 

[Blockmove]

Ein eigenes Modul für Modbus-Communication wär klasse.
Bin auch gerade in den Anfängen meine Wago mit fhem zu verheiraten.

Gruß und guten Rutsch
Dieter

[ChrisD]

Hallo,

Ein eigenes Modul für Modbus-TCP (und UDP ?) wäre sicher die schönste Lösung. Der Aufwand für ein solches Modul ist allerdings ziemlich hoch da die Daten u.a. zyklisch gepollt werden müssen. Da TCP-Verbindungen zu Hängern führen können, die dann z.B. die HMLAN-Kommunikation stören wäre zu überlegen für das Modul Non-Blocking-Aufrufe, ähnlich wie in http://forum.fhem.de/index.php/topic,17804.0.html für httputils zu verwenden.

Kurzfristig könnte man das aktuelle Modul leicht überarbeiten und jeder Funktion einen weiteren optionalen Parameter anhängen der entweder die IP-Adresse oder den Namen eines Dummys enthält, z.B.:

Code Auswählen Erweitern

define MBMaster_1 dummy
attr MBMaster_1 comment 192.168.123.45:502:1

Aus

Code Auswählen Erweitern

{read_modbus_zaehler(12288)}würde dann

Code Auswählen Erweitern

{read_modbus_zaehler(12288,"MBMaster_1")}

Grüße,

ChrisD

[oniT]

Hallo,

grundsätzlich wäre ein komplett eigenes Modul (mit allem drum und dran ) auch nicht schlecht. Mir würde zunächst schon einmal eine solche Umsetzung ausreichen.

Code Auswählen Erweitern

define MBMaster_1 dummy
attr MBMaster_1 comment 192.168.123.45:502:1

Code Auswählen Erweitern

{read_modbus_zaehler(12288,"MBMaster_1")}

Gruß,
Tino

[ChrisD]

Hallo,

Anbei eine neue Version von 99_modbus.pm mit folgenden Änderungen:

- die Parameter des Servers sind nur noch an einer Stelle im Code anzupassen
- die Funktion read_modbus gibt den gelesenen Wert zurück
- die Funktion read_modbus_zaehler fordert die Daten nicht mehr doppelt vom Server an
- die rollade-Funktionen sind entfernt
- write_modbus_coil wandelt intern die Werte on und off in 1 und 0 um, damit funktioniert auch

Code Auswählen Erweitern

write_modbus_coil(512,"on")
- alle read und write Funktionen nehmen einen optionalen Parameter an der entweder:
    - die IP-Adresse des Servers enthält, z.B.

Code Auswählen Erweitern

      read_modbus(12288,"192.168.12.34")
    - den Namen eines Dummys enthält, in diesem Fall werden im Dummy verschiedene Informationen zur Kommunikation angezeigt, z.B.

Code Auswählen Erweitern

      define MBMaster_1 dummy
      attr MBMaster_1 comment 192.168.123.45:502:1
      read_modbus_zaehler(12288,"MBMaster_1")
Das Kommentarfeld hat dabei den Aufbau IP-Adresse:Port:UnitID, wenn einer der Werte fehlt wird er durch den im Code vorgegebenen Wert ersetzt.

Der Code sollte abwärtskompatibel sein.

Grüße,

ChrisD

[bk9050]

Hallo,

zunächst mal ein Gutes Neues Jahr an alle.

Dann ein sehr großes Dankeschön an ChrisD für die geleistete Arbeit, es erspart mir sehr viel (vor allem in Perl tiefer einzusteigen). Bin erst seit wenigen Tagen hier Mitglied und Besitzer eines Raspberry mit FHEM 5.5. Der Plan ist, die Modbus-Geschichten zur Kommunikation mit meiner Beckhoff BC9000 SPS einzusetzen... wir sind im Geschäft mehr mit Beckhoff als mit WAGO 'verbandelt'. Der BC ist gegenwärtig  für die Licht-, Steckdosen- und Rollo-Steuerung von 3 Räumen zuständig, die Programmierung in ST ist noch nicht ganz abgeschlossen.

Sollte es einen Wiki-Artikel zur Modbus-Kopplung geben, wäre ich bereit mich parallel zu den eigenen Erfolgen (hoffentlich?) da auch einzubringen (Beckhoff-spezifisch).

Frage: Gibt es irgendwann ein Performance-Problem, wenn man viele Einzelbits (bei mir ca. 20-22 Inputs bzw. Outputs) jeweils als getrennte Modbus-Kommunikationsanfragen ausführt? Könnte man das irgendwie cachen (so wie es eine SPS intern auch macht) ?

Danke
Hermann-Josef
(Alias bk9050, von meinem ersten SPS-Projekt)

[ChrisD]

Hallo,

Einen Wiki-Artikel gibt es noch nicht, lechez hatte dies aber bereits vorgeschlagen.

Das aktuelle Modul ist was die Performance betrifft nicht optimal. Bei jedem Aufruf wird die TCP-Verbindung zum Server aufgebaut, die Anfrage geschickt, auf die Antwort gewartet und die TCP-Verbindung wieder geschlossen. Je nachdem wie schnell deine SPS ist dauert ein solcher Zyklus ein paar 100 ms. Wenn du also 20 Eingänge einzeln einliest wird FHEM für längere Zeit blockiert sein.

Ein Cachen wie bei der SPS ist nicht so einfach da diese am Zyklusanfang alle Eingänge liest und am Zyklusende alle Ausgänge schreibt, bei FHEM gibt es aber keinen Zyklusanfang und Zyklusende.

Wenn die Eingänge aufeinanderfolgend sind kannst du mehrere Eingänge mit dem FC1 auslesen, im Moment gibt es dafür aber keine fertige Funktion in 99_modbus.pm. Das Schreiben mehrere Coils ist über FC15 möglich, dieser ist aber noch nicht einmal in der zugrundeliegenden Datei MBClient.pm implementiert.

Die Kommunikation könntest du in einer getrennten Funktion in 99_myUtils.pm machen, der Ablauf wäre dann z.B.
- aufeinanderfolgende Eingangsdaten mit einer Anfrage lesen (FC1)
- gelesene Daten FHEM-Variablen (dummies) zuweisen und verarbeiten
- Ausgänge schreiben (FC15)

Alternativ kannst du 16 Bits in der SPS in ein Wort zusammenkopieren und dieses mit 'read_modbus' auslesen. Die Daten für die Ausgänge kannst du analog in FHEM in ein Wort packen, mit 'write_modbus' schreiben und im SPS-Programm die einzelnen Bits des Wortes den Ausgängen zuweisen.

Grüße,

ChrisD

[leibi]

Hallo, ein gutes neues Jahr euch allen zusammen!!!

bei mir läuft dank ChrisD die Modbus Geschichte mit Wago sowie B&R SPSen einwandfrei, die meisten werden wie ich wahrscheinlich hauptsächlich an der Visualisierung über Fhem interessiert sein, für die Logik ist die SPS stabiler.
Könnte man zum Anfang mit dem Frontend verstärkt beginnen?

Gruß
Markus

[oniT]

Hallo ChrisD,

wenn für die Abfrage jeden Wertes die TCP Verbindung geöffnet und wieder geschlossen werden muss, ist es bei Modbus dann möglich mehrere Register nach öffnen auf einmal abzufragen? Bisher Frage ich fast minütlich ca. 20 Werte ab und habe keine Probleme mit der Performance. Dies merke ich immer daran, wenn der HMLan disconnects bringt So lange dies nicht der Fall ist gibt es auch keine Probleme.

Ansonsten gutes Modul. Ich habe es zum Testen nun auch mit der neuen Version (IP Adresse über dummy) am Laufen. Bisher ohne Einschränkungen. Ich werde es mal in den kommenden Tagen auf weitere Geräte erweitern und schauen was dabei rauskommt.

Danke

Gruß,
Tino

[bk9050]

Hallo ChrisD,

Danke für Deine Überlegungen und Vorschläge.

Wenn die Eingänge aufeinanderfolgend sind kannst du mehrere Eingänge mit dem FC1 auslesen, im Moment gibt es dafür aber keine fertige Funktion in 99_modbus.pm. Das Schreiben mehrere Coils ist über FC15 möglich, dieser ist aber noch nicht einmal in der zugrundeliegenden Datei MBClient.pm implementiert.

Die Kommunikation könntest du in einer getrennten Funktion in 99_myUtils.pm machen, der Ablauf wäre dann z.B.
- aufeinanderfolgende Eingangsdaten mit einer Anfrage lesen (FC1)
- gelesene Daten FHEM-Variablen (dummies) zuweisen und verarbeiten
- Ausgänge schreiben (FC15)

Alternativ kannst du 16 Bits in der SPS in ein Wort zusammenkopieren und dieses mit 'read_modbus' auslesen. Die Daten für die Ausgänge kannst du analog in FHEM in ein Wort packen, mit 'write_modbus' schreiben und im SPS-Programm die einzelnen Bits des Wortes den Ausgängen zuweisen.

OK, mehrere Werte lesen (hier über FC3) habe ich hinbekommen und auch den Zugriff darauf.

Wenn ich es richtig verstanden habe, kann ich mit read_coil() etc. nicht auf den Merker-Bereich zugreifen. Da alle DI/DO der SPS zugeordnet sind, kann ich mit den coil-Funktionen nichts anfangen (korrigiere mich, wenn ich falsch liege).
Ein/Ausmaskieren eines Bits, das geht auch.

Wie mache ich es, dass die vorgeschlagene 99_myUtils.pm die Funktionen in 99_modbus.pm nutzen kann?

Code Auswählen Erweitern


use 99_modbus.pm;

verletzt scheinbar wohl Namens-Konventionen für Perl-Module?
Aus irgendwelchen Gründen wird ein minimales (= entsprechend des Template) 99_myUtils.pm bei FHEM zum Editieren angezeigt, 99_modbus.pm taucht da bei mir nicht auf.

Zu guter Letzt, ist es normal, dass sich fhem.pl aufhängt, wenn man einen Perl-Fehler gemacht hat? Es lässt sich dann auch nicht mehr via /etc/init.d/fhem stop stoppen?

Momentan wühle ich mich wieder durch die Beispiele, um eine Art toggle hinzukriegen. Damit soll dem FB in der SPS ein Taster simuliert werden, wenn man das Lampensymbol in FHEM betätigt (ähnlich Eltako Stossstromrelais).

Danke und Grüße
Hermann-Josef