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

[oniT]

Nach dem Start von FHEM sollte das Attribut automatisch gelöscht werden was aber anscheinend nicht mehr funktioniert. Ich muss mir das genauer ansehen.

Hallo ChrisD,

ah na ja, vielleicht ist es auch das. Ich habe ein Reload und keinen Neustart durchgeführt.

Gruß
Tino


Gesendet von meinem iPhone mit Tapatalk

[der-Lolo]

Hm, ich glaube wir kommen der Sache näher...
Ich habe nun in FHEM alles so gelassen wie es ist (MW200 ; MW201)
In der Wago Variablen Deklaration habe ich Kaltlicht also MW201 auf MW202 gesetzt.
So funktioniert alles wie gewünscht.
Aufgefallen war mir "online" das im Array abDMX_Values beim verändern von MW201 die Kanäle abDMX_Values[2] und [3] verändert werden.
Nun mit MW202 innerhalb der Wago und MW201 innerhalb FHEM verändert sich der Wert nur noch auf abDMX_Values[3].
abDMX_Values ist in der Wago Deklaration auf

Code Auswählen Erweitern

abDMX_Values (%MW200) gesetzt.
Ich verstehe zwar den zusammenhang nicht, vielleicht stimmt aber auch an dieser Stelle etwas mit den Wago Bausteinen für DMX nicht.

Die Werte die Du gerne sehen möchtest - kann ich die in einen Trace packen?
Ich habe keine Ahnung wie ich die Daten bekomme die DU gerne sehen möchtest...

btw: 1000 Danke für Deine Hilfe!

[pc1246]

Hallo der-Lolo
Das MW200 beinhaltet Teile des MW201. Das ist nun mal so! Ein Wort hat 16 Bit(2 Byte), zwischen 200 und 201 sind aber nur 8 Bit(1 Byte)! Das naechste Wort ist immer 2 Byte weiter, also MW200 dann MW202 usw.!
Gruss Christoph

[der-Lolo]

Hallo pc1246,
danke fürs mitdenken! Ich habe gedacht das ich in der deklaration bestimme welche Datentypen in den bereichen abgelegt werden. MW200 und MW202 sind als BYTE deklariert, das denoch ein WORD daraus gemacht wird war mir nicht klar.
Ich denke ich sollte den bereich wechseln um nur Bytes zu händeln...

[ChrisD]

Hallo,

Wago verwendet ein etwas ungewöhnliches Speicherlayout so dass MW201 keinen Teil von MW200 belegt. MW200 belegt die Bytes MB400 und MB401 während MW201 die Bytes MB402 und MB403 belegt. Den gleichen Speicherbereich belegt auch noch MD100.

Der DMX-Baustein benötigt ein Array mit Bytes was nicht so gut zu den Daten die per Modbus übertragen werden passt.

Aufgefallen war mir "online" das im Array abDMX_Values beim verändern von MW201 die Kanäle abDMX_Values[2] und [3] verändert werden.

Bei deiner Deklaration belegt abDMX_Values[0] und [1] MW200 und abDMX_Values[2] und [3] MW201. Wenn du z.B. RGBW-LEDs verwendest und nur die Helligkeit ändern möchtest sollte dies über abDMX_Values[3] und abDMX_Values[7] funktionieren, also den High-Bytes von MW201 und MW203. Bei RGBW werden 4 Bytes pro Teilnehmer benötigt.

Verwendest du nur FbDMX_652_Master oder auch andere Bausteine aus der Wago-DMX-Bibliothek ? Wird nur über FHEM auf DMX zugegriffen oder auch sonst noch aus dem SPS-Programm ? Welche Art von LEDs steuerst du über DMX ?

Grüße,

ChrisD

[der-Lolo]

Hallo ChrisD,
ich verwende den masterbaustein und einen FB_ChangeChanelValues - zur Zeit bin ich auch noch nicht glücklich was das ganze angeht, ich würde gerne lieber Dimm Rampen fahren. Und vorallem direkt in der SPS ohne FHEM Leuchten einschalten. Zur zeit macht das ein DOIF - ( set warmlicht 200 ) wenn out1 on ist.
Als Dimmer kommt ein ELDOLED 180D2 zum Einsatz, Leuchmittel sind LEDs von Voltus.
RGB kommt sicher auch später mal zum Einsatz, zur zeit geht es aber nur um normales 2700K Licht. Ich wünschte ich würde diese DMX Sachen etwas besser verstehen...

Die Merkerbereiche muss ich jedenfalls noch besser verstehen sodass ich sinnvoll deklarieren und zuweisen kann...

Hast Du vielleicht noch Lesestoff Empfehlungen speziell für Wago?

[ChrisD]

Hallo,

Wenn dein Dimmer bei CCWW 4 Kanäle belegt sollte deine Konfiguration richtig sein, wahrscheinlich ist FB_ChangeChanelValues aber nicht nötig. Dadurch dass du abDMX_Values auf %MW200 gelegt hast sollten die Werte die du über FHEM auf MW200 und MW201 schreibst direkt per DMX ausgegeben werden.

Wie hast du FB_ChangeChanelValues konfiguriert ?

Zur zeit macht das ein DOIF - ( set warmlicht 200 ) wenn out1 on ist.

Was ist out1 ? Wenn es von der SPS kommt kannst du den Weg über FHEM sparen und die Werte direkt zuweisen, z.B. über ein SEL.

Für Dimmrampen kannst du z.B. den Baustein RAMP_INT aus der Bibliothek util.lib verwenden, damit lassen sich Rampen ziemlich flexibel konfigurieren. Du musst dir dann aber überlegen ob und wie du die Vorgabe (Sollwert) von dem aktuellen Istwert in FHEM trennst.

Die Merkerbereiche muss ich jedenfalls noch besser verstehen sodass ich sinnvoll deklarieren und zuweisen kann...

Feste Adressen sind nur in bestimmten Fällen nötig, z.B. bei Wago bei der Modbuskommunikation. Variablen die nur intern im SPS-Programm verwendet werden benötigen keine Adresse, der Compiler kümmert sich selbst darum.

Hast Du vielleicht noch Lesestoff Empfehlungen speziell für Wago?

Nein, habe ich leider nicht. Es gibt zwar die Dokumentation von Wago und CoDeSys sowie diversen Application Notes, es ist aber nicht immer einfach darin das Richtige zu finden.

Grüße,

ChrisD

[golli]

Hallo,
versuche gerade auch meine Wago 750-881 mit 192.168.115.100 per Modbus an mein FHEM auf Raspberry mit 192.168.115.52 zu koppeln.
In der 99_modbus.pm habe ich ,,$m->host("192.168.115.100");" geändert.
Hier die Globalen Variablen meiner Wago:


Wie bekomme ich jetzt z.B. die Aussentemperatur in FHEM?

[ChrisD]

Hallo,

Mit der 99_modbus.pm ist es etwas schwieriger REAL-Zahlen zu lesen.

Einfacher geht es mit den Modulen 36_ModbusTCPServer und 37_ModbusRegister. Du kannst die aktuelle Version mit

Code Auswählen Erweitern

update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbustcp.txt

installieren. Nach einem Neustart von FHEM kannst du die Verbindung zur SPS mit

Code Auswählen Erweitern

define wago ModbusTCPServer 192.168.115.100anlegen.

Im SPS-Programm musst du die Variablen die ausgetauscht werden sollen in den Merkerbereich legen, z.B.

Code Auswählen Erweitern

Aussentemperatur AT %MD100 : REAL;

Mit

Code Auswählen Erweitern

define Aussentemperatur ModbusRegister wago MF100
wird die Temperatur von FHEM gelesen.

Da bei jedem Lesezyklus der Wert aktualisiert wird kannst du noch zusätzlich

Code Auswählen Erweitern

attr Aussentemperatur event-on-change-reading .*
verwenden. Dadurch wird nur bei Änderungen ein Ereignis (z.B. für Logging) in FHEM generiert.

Die Datei 99_modbus.pm brauchst du nicht mehr.

Grüße,

ChrisD

[golli]

Wenn ich mit Putty : update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbustcp.txt
eingebe erhalte ich folgende Fehlermeldung:
-bash: update: command not found

[suppenesser]

Nicht in putty, im fhem comandofenster eingeben

Gesendet von meinem HUAWEI GRA-L09 mit Tapatalk

[golli]

Super das funktioniert schon mal, danke euch.
Wenn ich jetzt noch die digitalen Ein- und Ausgänge einbinden möchte, z.B.

esszimmer_taster1(%IX2.2) digitaler Eingang

schalo_esszimmer_sued_up (%QX6.0) digitaler Ausgang

[ChrisD]

Hallo,

Für das direkte Lesen/Schreiben der Ein- und Ausgänge muss FHEM die Konfiguration der SPS kennen. Dazu musst du das Attribut serverType setzen:

Code Auswählen Erweitern

attr wago serverType Wago

Mit

Code Auswählen Erweitern

list wagokannst du kontrollieren ob es funktioniert hat, du solltest in der Ausgabe Informationen der Art

wago:
       AI         12
       AO         10
       DI         8
       DIOffset   192
       DO         4
       DOOffset   160
       INFO_ITEM  880
       INFO_MAJOR 2
       INFO_MINOR 3
       INFO_REVISION 5
       INFO_SERIES 750
       initDone   1
       x          1

finden.

Anschließend kannst du die Eingänge mit

Code Auswählen Erweitern

define esszimmer_taster1 ModbusCoil wago IX2.2
attr esszimmer_taster1 event-on-change-reading .*
definieren.
Wenn der Tastimpuls am Eingang kürzer als der Abfragezyklus ist, kann es passieren dass FHEM den Taster nicht sieht, in dem Fall kannst du auf der SPS einen TP- oder TOF-Baustein verwenden um den Tastimpuls zu verlängern.

Für die Ausgänge:

Code Auswählen Erweitern

define schalo_esszimmer_sued_up ModbusCoil wago QX6.0
attr schalo_esszimmer_sued_up event-on-change-reading .*
Du kannst aber nur auf den Ausgang schreiben wenn das SPS-Programm dies nicht tut.
Falls FHEM und die SPS gleichzeitig auf den Ausgang zugreifen sollen, muss FHEM einen Merker in der SPS schreiben und du musst diesen ins SPS-Programm einbinden.

Grüße,

ChrisD

[golli]

Super dank dir, ich kann jetzt auf der Oberfläche von FHEM sehen, wenn ich z.B. einen Licht Taster betätige.
Problem ist jedoch, dass ich Stromstoss Schalter in der Verteilung verbaut habe. So wie auf dem Bild habe ich das in Codesys gelöst.
buero_taster1 ist der Taster im Raum, buero_unten_licht_button ist für der Lichttaster für die Visualisierung, buero_unten_licht ist der digitale Ausgang(schaltet den Stromstoss Schalter).
Für FHEM passt der Status vom Licht jedoch nicht.

[ChrisD]

Hallo,

Du könntest den Zustand von 'buero_unten_licht_feedback' in FHEM verwenden, da dieser den (wahrscheinlichen) Zustand des Stromstossschalters enthält. Wenn buero_unten_licht_feedback auf MX100.0 und buero_unten_licht_button auf MX120.0 liegen sollte dies funktionieren:

Code Auswählen Erweitern

define buero_unten_licht ModbusCoil wago MX100.0
attr buero_unten_licht event-on-change-reading .*
attr buero_unten_licht writeMode Impulse:MX120.0


Dadurch wird der Zustand von MX100.0 gelesen, Befehle werden aber als Impulse an MX120.0 gesendet.

Grüße,

ChrisD