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

[Tho-Gra]

Hallo,

Die aktuelle Version befindet sich in Beitrag 151.

Der Thread ist in der Tat unübersichtlich geworden, ich werde versuchen die aktuellen Versionen in einem Wiki-Artikel abzulegen.

Grüße,

ChrisD

Hallo alle zusammen,

Bin gerade dabei meine Beckoff mittels Modbus mit FHEM zu verbinden.
Einen Wiki Artikel habe ich noch nicht gefunden - gibt es diesen mittlerweile?
Ist die aktuellste Version noch die von Beitrag 151?

Vielen Dank für die bereits getane Mühe.

Grüße

Tho-Gra

[bk9050]

Hallo Tho-Gra,

welche Beckhoff-Steuerung setzt Du ein?

Ich benutze BC9000 und habe die auch mal testweise mit FHEM via Modbus verbunden. Hier gibt es auch noch etwas dazu:

http://www.mikrocontroller.net/topic/325144#new

Code-Example bei Bedarf (für den Testaufbau).

Endgültig ist meine Steuerung noch nicht völlig fertig, aber im Prinzip fuktionierte das mit dem FHEM schon ganz gut.

Viel Erfolg
Hermann-Josef (bk9050)

[Tho-Gra]

Hi bk9050,

Ich habe eine BX9000. Muss gestehen das ich bisher noch sehr verwirrt bin. Habe noch nie mit Modbus gearbeitet.

Könntest du mir einen Auszug aus deinen Programmen zukommen lassen?


Eine weitere Frage hätte ich da noch.
Was genau ist ein Coil?

Vielen Dank

Grüße

Tho-Gra

PS: Ich lese mich nun durch dein Link durch - Danke nochmal dafür

[bk9050]

Hi Tho-gra,

ein coil ist ein schaltbares Bit. Siehe hier:

http://en.wikipedia.org/wiki/Modbus

"Many of the data types are named from its use in driving relays: a single-bit physical output is called a coil, and a single-bit physical input is called a discrete input or a contact."

Ja, ich versuche Dir das zu schicken. Du solltest das Projekt in das Beckhoff-Tool einlesen (importieren können), denke ich.

Gruß
Hermann-Josef (bk9050)

[ChrisD]

Hallo,

Der Link in Beitrag 151 verweist noch immer auf die aktuelle Version. Einen Wiki-Artikel gibt es noch immer nicht, ich bin aber dabei die Dokumentation der Module fertigzustellen und werde mich danach ums Wiki kümmern.

Grüße,

ChrisD

[Dieter1]

Hallo ChrisD,

danke für deine Modbus Module. Super.

Ich habe einen Stromzähler SDM630 mit RS485/Modbus Anschluss.
Da ich noch weitere RS485 Messstellen plane, meine seriellen Anchlüsse begrenzt sind und neue serielle Leitungen mir ein Greuel sind  wollte ich auf das setzen, was ich überall verfügbar habe: TCPIP over LAN, WLAN oder dLAN.
Lösung: Modbus über TCPIP schicken und vorort in RS485 wandeln. TCPIP<->RS485 Wandler (TCP232-24, ca. 20,- € bei ebay)

Ich benötige als Protokoll also nicht ModbusTCP, sondern schicke nur ModbusRTU über TCP.

Da dein Modul 36_ModbusRTU.pm auf DevIO.pm aufsetzt war das kein Problem. 2 kleine Erweiterungen sind erforderlich:
1. Akzeptieren von TCPIP:Port Adressen:
    ModbusRTU_Define fügt in Init bei fehlender Baudrate "@9600" an. Damit ist eine IP:Port Adresse für DevIO nicht mehr erkennbar.
    Die Zeile "$dev .= "\@9600" if( $dev !~ m/\@/ );" habe ich bei mir auskommentiert. Bitte erweitere die Erkennung auf TCPIP:Port Adressen und füge dann keine Baudrate hinzu.
2. In ModbusRTU_SimpleWrite neben USB und DIO auch die Option TCP hinzufügen:
    $hash->{USBDev}->write($msg)    if($hash->{USBDev});
    syswrite($hash->{DIODev}, $msg) if($hash->{DIODev});
   syswrite($hash->{TCPDev}, $msg) if($hash->{TCPDev});

Mit diesen beiden Änderungen funktioniert ModbusRTU über TCPIP prima. Bitte baue das in dein Modul ein, ist sicher auch für andere interessant und ich möchte dein Standardmodul nutzen.

Hier als Beispiel meine Definition mit Abfrage der Phase 1 des Stromzählers in W.
1 ist die ModbusAdresse des Stromzählers, 12 das Register im Stromzähler für P1.

Code Auswählen Erweitern


define EVU_Meter ModbusRTU 192.168.178.101:20108

define EVU_P1_P ModbusRegister 1 12
   attr EVU_P1_P IODev EVU_Meter
   attr EVU_P1_P plcDataType REAL_BE
#   attr EVU_P1_P registerType Holding
   attr EVU_P1_P registerType 4   # Input
   attr EVU_P1_P disableRegisterMapping 1
   attr EVU_P1_P stateFormat {sprintf("%d", ReadingsVal($name,"state",0))}
   attr EVU_P1_P updateIntervall 60
   attr EVU_P1_P userReadings W {sprintf("%d", ReadingsVal($name,"state",0))}
#   attr EVU_P1_P verbose 5


Mehrere Geräte an einem "lokalen" Modbus sollten kein Problem sein, habe ich aber noch nicht ausprobiert. Jedenfalls kann ich damit orts- und portunabhängig viele Modbusse ansprechen.

Danke noch einmal für deine Modbus Implementierung

Dieter

[Dieter1]

Hallo ChrisD,

auf ein Problem bin ich in den Modbus Modulen gestossen:
Attribute "registerType Input" funktioniert nicht, da musste ich "registerType 4" verwenden, ansonsten ist das Ergebnis immer "3" (=Holdung).
Gleiches gilt, wenn "disableRegisterMapping 1" vor "registerType 4" angegeben wird, dann ist das Ergebnis "registerType 3".

Es wird also  "SimpleWrite 01 03 00 0C 00 02 04 08"
anstelle von  "SimpleWrite 01 04 00 0C 00 02 B1 C8" gesendet.

Diese Definition unten funktioniert zwar, aber so hattest du das bestimmt nicht gedacht:

define EVU_P1_P ModbusRegister 1 12
   attr EVU_P1_P IODev EVU_Meter
   attr EVU_P1_P plcDataType REAL_BE
#   attr EVU_P1_P registerType Holding
   attr EVU_P1_P registerType 4   # Input
   attr EVU_P1_P disableRegisterMapping 1

Grüsse

Dieter

[ChrisD]

Hallo,

Danke für den Hinweis für die Verbindung über TCP/IP, ich werde das Modul dementsprechend anpassen.

Was die Funktion von registerType und disableRegisterMapping angeht ist es etwas komplizierter. Das Attribut disableRegisterMapping wurde eingeführt für die Kommunikation mit Wago-Steuerungen da bei diesen mit Adressen (0-basiert) und nicht mir Registernummern (1-basiert) gearbeitet wird. Wenn registerType auf 4 gesetzt wird sollte dies das gleiche bewirken wie wenn registerType nicht auf 'Input' steht da nur dies abgefragt wird. Ich werde mir den Code nochmal ansehen.

Für deine Anwendung sollte disableRegisterMapping auch nicht nötig sein, in der Dokumentation des SDM630 sind 'normale' Registernummern angegeben, kannst du versuchen die Definition so zu ändern:

Code Auswählen Erweitern

define EVU_P1_P ModbusRegister 1 30013
   attr EVU_P1_P IODev EVU_Meter
   attr EVU_P1_P plcDataType REAL_BE


Dadurch sollte automatisch FC4 zum Lesen des Eingangsregisters auf Adresse 12 verwendet werden.

Grüße,

ChrisD

[ChrisD]

Hallo,

Ich habe den Fehler mit disableRegisterMapping und registerType gefunden und behoben. Kannst du es bitte nochmal mit deiner ursprünglichen Konfiguration testen ?

Grüße,

ChrisD

[Dieter1]

Hallo ChrisD,

jetzt funktioniert alles.

- Die IP Adressierung funktioniert:   define EVU_Meter ModbusRTU 192.168.178.101:20108
- disableRegisterMapping und registerType funktionieren jetzt in beliebiger Reihenfolge. Bei Registertype geht es nicht mehr mit der "4", aber mit "Input" geht es. So soll es sein

Hier meine Definitionen und das Ergebnis:
define EVU_ES_E ModbusRegister 1 74    # Export Power Summe in kWh
attr EVU_ES_E IODev EVU_Meter
attr EVU_ES_E event-on-change-reading .*
attr EVU_ES_E plcDataType REAL_BE
attr EVU_ES_E disableRegisterMapping 1
attr EVU_ES_E registerType Input

2015.02.17 06:58:20 5: AddRQueue 01 04 00 4A 00 02 50 1D
2015.02.17 06:58:20 5: SimpleWrite 01 04 00 4A 00 02 50 1D
2015.02.17 06:58:20 5: Read 01 04 04 43 68 FC EE AE 90
2015.02.17 06:58:20 5: Received 01 04 04 43 68 FC EE AE 90
2015.02.17 06:58:20 5: EVU_Meter dispatch ModbusRegister:1:74:4:2:17256:64750
2015.02.17 06:58:20 5: ModbusRegister_Parse: 4 1 74

Danke noch einmal, ich hoffe deine Module gibt es bald als FHEM Standardmodule.

Jetzt werde ich mich in die Tiefen von "statistics" stürzen. Falls da jemand eine funktionierende Beispieldefinition incl. schreiben in ein Log kennt wäre ich für einen Tip dankbar, bisher finde ich nur kleine unvollständige Schnipsel.

Grüsse

Dieter

[ChrisD]

Hallo,

Für den Einsatz von 'statistics' und ähnlichem Code der über 'notify' funktioniert gibt es das Attribut stateAlias. Damit wird ein zusätzliches Reading erzeugt:

Code Auswählen Erweitern

attr EVU_ES_E stateAlias energy
attr EVU_P1_P stateAlias power

Die zusätzlichen Readings sind jeweils eine Kopie von 'state', sie können aber direkt von 'statistics' ausgewertet werden.

Grüße,

ChrisD

[oniT]

Hallo ChrisD,

Pah hat im Wiki darauf hingewiesen das "updateIntervall " im Englischen ja "updateInterval" heißt. Ist ja nichts schlimmes und ich weiß auch nicht ob man dies im Nachhinein überhaupt noch ändern kann, ohne die bisherigen angelegten Definitionen zu beeinflussen.

Dies mal so am Rande.

Und noch etwas, bei mir kommt im Logfile immer mal "ModbusTCPServer: bad frame". Was sagt dies aus?

Danke

Gruß,
Tino

[ChrisD]

Hallo,

Ich habe das Attribut in der Version 0011 (Register) und 0005 (Coil) geändert. Damit es übernommen wird muss FHEM neu gestartet werden, die alte Schreibweise wird dann automatisch konvertiert.

Die Meldung 'bad frame' besagt dass ein Paket empfangen wurde das entweder nicht erwartet wurde oder aber nicht vollständig ist. Ich habe die Ausgabe von 36_ModbusTCPServer etwas erweitert, kannst du den Loginhalt beim nächsten Fehler posten ?

Grüße,

ChrisD

[oniT]

Hallo ChrisD,

danke, ich habe es eingespielt.

Noch eine Frage dazu, hast Du den Loginhalt erweitert oder muss ich das Loglevel ändern?

Und gibt es eine Möglichkeit den Startzeitpunkt für das updateInterval zu bestimmen? Also wie zum Beispiel bei einem at mit alignTime. Hintegrund ist, es gibt Abfragen welche nur stündlich (z.B. zur vollen Stunde) oder täglich (z.B. bei Tageswechsel) stattfinden sollen. Wenn man dies direkt anlegen könnte, muss nicht den Umweg über ein at und notify gehen.

Danke

Gruß,
Tino

[oniT]

Hallo ChrisD,

ich nehme an, Du meinst diese Meldung im Logfile

Code Auswählen Erweitern


2015.02.22 16:11:32 1: -6
2015.02.22 16:11:32 1: PERL WARNING: Argument "ModbusTCPServer: bad frame: 3 - 8, 0, 5 - 33" isn't numeric in subtraction (-) at ./FHEM/36_ModbusTCPServer.pm line 253.


Diese Meldung kommt nun seit dem einspielen der neuen ModbusTCPServer.pm.

Gruß,
Tino