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

Begonnen von lechez, 05 Mai 2013, 10:50:13

Vorheriges Thema - Nächstes Thema

Gungnir

Hallo,

ich verfolge und lese das Thema zu Modbus TCP jetzt schon eine ganze Weile und hab dadurch auch schon ein klein bisschen was über Modbus erfahren können. Leider habe ich jetzt mit meiner aktuellen Konfiguration einen Kampf, bei dem ich nicht ganz weiter kommen.

Mein Setup:
SPS: Beckhoff CP6707 mit Twincat 2 und installeierten Modbusserver.
        eine Merker-Varaible mBus_RainWaterLevel    AT%MB100:REAL;

FHEM: in der aktuellen Version auf einem Raspberry

  • 36_ModbusTCPServer.pm, 37_ModbusCoil.pm , 37_ModbusRegister.pm von GITHUB gecloned
  • define SPS01 ModbusTCPServer 10.0.0.250 definiert
  • define RainWaterLevel ModbusRegister SPS01 MF100

Ich habe FHEM mal rebooted.
Im FHEM-Logfile finde ich leider nur immer wieder den Eintrag
2017.09.26 20:31:27 2: ModbusRegister_Parse: invalid address 3 0 0
2017.09.26 20:31:27 2: ModbusRegister_Parse: invalid address 3 0 0
2017.09.26 20:31:27 3: SPS01: Unknown code ModbusRegister:0:0:3:1:384, help me!
2017.09.26 20:31:27 2: ModbusRegister_Parse: invalid address 3 0 0
2017.09.26 20:31:27 2: ModbusRegister_Parse: invalid address 3 0 0
2017.09.26 20:31:27 3: SPS01: Unknown code ModbusRegister:0:0:3:1:384, help me!


Ich bin bei Modbus völlig neu, daher bin ich da wahrscheinlich etwas blind, was eine möglich Lösung angeht. Gibt es beim Zugriff per Modbus auf Beckhoff möglicherweise etwas zu beachten?

LG und vielen Dank im Voraus

Gungnir

ChrisD

Hallo,

Kannst du versuchen die Definition von
define RainWaterLevel ModbusRegister SPS01 MF100
in
define RainWaterLevel ModbusRegister wago MF100
umzuändern ?

Der Begriff 'wago' bezieht sich auf die Adressierungsart resp. das Mapping von SPS- zu Modbus-Adressen. Die Zuordnung zum ModbusTCPServer erfolgt automatisch durch FHEM (zumindest solange du nur einen hast).

Grüße,

ChrisD

Gungnir

Hallo ChrisD,

vielen Dank für die rasche Antwort.

ich habe noch mal Google bemüht und bin dann auf eine andere Definition gestoßen.

ich hab es jetzt so gemacht:

define RainWaterLevel ModbusRegister 1 12288
attr RainWaterLevel plcDataType REAL
attr RainWaterLevel disableRegisterMapping 1


damit hat es dann auch geklappt.

Eine Frage habe ich aber noch fürs Verständnis:die 12288, was genau ist da für ein Wert? Ist das der 12288. Register im Speicherabbild.

LG Gungnir

ChrisD

Hallo,

Bei Wago und Beckhoff kannst du ab Modbus-Adresse 12288 auf den Speicherbereich ab MW0 zugreifen. Die Definition mit 'wago' bei ModbusRegister (und ModbusCoil) nimmt dir nur die Berechnung der korrekten Adresse ab und trägt automatisch die richtigen Datentypen ein. MF100 liegt bei Wago z.B. auf den Modbus-Adressen 12688 und 12689.

Grüße,

ChrisD

Gungnir

#424
Hallo,

ok, verstehe. Ich habe jetzt 2 REAL-Werte von meine Beckhoff gelesen.

das sieht so aus:

define RainWaterLevel ModbusRegister 1 12288
attr RainWaterLevel plcDataType REAL
attr RainWaterLevel disableRegisterMapping 1
attr RainWaterLevel event-on-change-reading .*


define TemperaturWater ModbusRegister 1 12290
attr TemperaturWater plcDataType REAL
attr TemperaturWater disableRegisterMapping 1
attr TemperaturWater event-on-change-reading .*


Meine Varaiblendeklaration in der SPS ist so:

       
        mBus_RainWaterLevel AT%MB0:REAL; (* 12288*)
mBus_TempWater AT%MB4:REAL;    (*  12290*)

        MBus_State1                   AT%Mx8.0:BOOL;    (*  12292*)


Muss ich dann mit define State1 ModbusRegister 1 12292.0 von FHEM aus aud einen boolschen Wert zugreifen?

LG

ChrisD

#425
Hallo,

Für den Zugriff auf BOOL kannst du ModbusCoil verwenden, ModbusRegister ist für 16-Bit Werte.

In der Dokumentation von Beckhoff habe ich kein Mapping für Coils auf SPS-Speicherbereiche gefunden. Du kannst versuchen ob
define state1 ModbusCoil wago MX8.0
funktioniert.

Grüße,

ChrisD

Gungnir

Hallo,

danke für die Info.

eine Frage habe ich jetzt noch. Wie muss ich vorgehen, wenn ich per Modbus von FHEM aus eine Variable in der Beckhoffsteuerung schreiben möchte?

z.B. eine Zielthemperatur für eine Heizungsansteuerung.

LG

ChrisD

Hallo,

Wenn du eine Variable in der SPS für die Solltemperatur deklarierst und auf diese über ModbusRegister zugreifst, kannst du den Wert mit dem 'set'-Befehl von FHEM setzen.

Grüße,

ChrisD

der-Lolo

Hallo ChrisD,
Ich habe gerade etwas eigenartiges im Logfile meiner FHEM installation entdeckt.
Zitat
2017.10.08 18:25:35 0: Cant open FHEM/perfmon at ./FHEM/98_help.pm line 235.
2017.10.08 18:22:34 3: RBadOben: I/O device is WagoController
2017.10.08 18:21:20 3: RBadOben: I/O device is modbusRTU
2017.10.08 14:05:15 2: ROOMMATE set rr_Christin home
2017.10.08 11:04:33 2: ROOMMATE set rr_Christin absent

RBadOben ist ein
Internals:
   CFGFN
   CHANGED
   DEF        wago MX1.4
   IODev      WagoController
   LASTInputDev WagoController
   MSGCNT     106023
   ModbusCoil_lastRcv 2017-10-09 23:55:24
   NAME       RBadOben
   NR         127
   NTFY_ORDER 50-RBadOben
   STATE      off
   TYPE       ModbusCoil
   WagoController_MSGCNT 106023
   WagoController_TIME 2017-10-09 23:55:24
   lastUpdate Mon Oct  9 23:55:23 2017
   nextUpdate Mon Oct  9 23:55:24 2017
   READINGS:
     2017-10-09 23:55:24   state           off
   helper:
     addr       1 0 12308
     address    12308
     disableRegisterMapping 1
     lastUpdate 1507586123.89598
     nextUpdate 1507586124.79766
     nread      8
     readCmd    0
     register   12308
     registerType 1
     unitId     0
     updateIntervall 0.1
     wago       1
     wagoDOOffset 0
     wagoT      M
     writeMode:
       DO         0
       addr       1 0 12468
       address    12468
       impDuration 0.5
       register   MX11.4
       registerType 1
       type       IM
Attributes:
   IODev      WagoController
   alias      Rolladen Badezimmer Oben
   event-on-change-reading .*
   group      Switch
   room       90 - Testumgebung,02-BadOben
   writeMode  Impulse:MX11.4



Ich nutze Dein Modbus Modul für ModbusTCP mit meiner Wago - ausserdem habe ich Stefans Modbus Modul definiert um eine ModbusRTU linie abfragen zu können.

Hast Du eine Idee was den wechsel des I/O Devices verursachen kann?
Komisch ist ja auch das es sich um nur einen Switch handelt und nicht um 14...

ChrisD

Hallo,

Es ist schwierig zu sagen woran es genau liegt. Ich habe versucht mir das Modul von Stefan anzusehen, ich habe aber nichts gefunden was erklären würde wieso es von FHEM überhaupt als I/O-Device ausgewählt wird.

Sind die Meldungen nach einem Neustart oder rereadcfg gekommen ? In dem Fall könnte es an der Reihenfolge der Geräte in der Konfigurationsdatei liegen.

Grüße,

ChrisD

der-Lolo

Ja, die reihenfolge - das könnte es sein...
RBadOben habe ich erst kürzlich hinzugefügt, ich pass das mal an..

der-Lolo

Hallo ChrisD,
es hängt tatsächlich an der Reihenfolge - da ich aber den ModbusRTU eh erstmal nicht sauber auf der Synology DiskStation ans laufen bekomme habe ich den RTU Part wieder rausgeworfen und auf einem RPI3 am laufen.

Meine nächste Baustelle sind nun die Rolläden, wie würdest Du diese Programmieren? Ich möchte ja auch gerne von FHEM aus auf z.b. 70% fahren können. Von den Tastern aus denke ich kurz drücken fahren in Endlage, gedrückt halten fahren bis ich loslasse... 
Ich müsste also für jeden Rollo individuell die Laufzeit ermitteln und von FHEM aus sagen x sekunden in richtung y fahren....

PS: mein Hardware problem hat sich gelöst, die Karten die mir mein großhändler angedreht hat sind negativ schaltend.

Grüße aus Berlin.

ChrisD

Hallo,

Ich würde die Steuerung der Rollläden komplett auf der SPS machen. Von FHEM aus würde ich nur eine Position vorgeben die angefahren werden soll sowie Befehle für komplett auf und komplett zu.

Für die Steuerung in der SPS gibt es mehrere Möglichkeiten:
- du schreibst alle selbst
- du baust auf dem Baustein FbJalousie von Wago auf
- du verwendest die Bausteine BLIND_CONTROL_S und BLIND_INPUT aus der Oscat-Bibliothek

Du musst auf jeden Fall die Laufzeiten ermitteln damit du ungefähr positionieren kannst.

Grüße,

ChrisD

der-Lolo

Ok, ich habe heute alle Rolläden mit einem eigenem FB_Jal in betrieb genommen - über ein TOF fahre ich auf Tastendruck jeweils die Endlagen an. Ausserdem habe ich in FHEM mit ModbusCoil die Trigger für auf und ab an jedem Rollo inkl. rückmeldung integriert.
Ich habe nun 32 ModbusCoil im Einsatz x2 also jeweils mit rückmeldung. Ausserdem 13 ModbusRegister um Dimm-Werte zu übertragen.

Bilde ich mir das nur ein? Oder ist die aktualisierung der response schon langsamer geworden?


Was die möglichkeiten der Steuerung angeht könnte ich doch wieder einen VAR IN OUT benutzen - um zumindest grob auf % fahren zu können und eine Anzeige der Position zu haben. Bei jedem voll geöffnet könnte man ja einen Reset setzen, damit es nicht auseinanderdriftet...

Bei 20sekunden laufzeit käme ich ja sogar Prozentgenau von der auflösung her hin - wobei man ja auch die ModbusCoil BITS in ein Register stecken könnte.

ChrisD

Hallo,

ZitatBilde ich mir das nur ein? Oder ist die aktualisierung der response schon langsamer geworden?
Hast du das Attribut combineReads beim Server gesetzt ?

Wenn nicht kannst du es mit
attr WagoController combineReads 20:80
versuchen. Dadurch werden die Leseaufträge so weit wie möglich zusammengefasst. So wird z.B. statt 32 Aufträgen mit 1 Coil nur 1 Auftrag mit 32 Coils erzeugt.

ZitatWas die möglichkeiten der Steuerung angeht könnte ich doch wieder einen VAR IN OUT benutzen
Ja, die Ansteuerung der Rollos unterscheidet sich im Prinzip nicht allzuviel vom DMX.

Zitatwobei man ja auch die ModbusCoil BITS in ein Register stecken könnte
Das ist zwar im Prinzip möglich, das Handling in FHEM ist aber ziemlich schwierig.

Grüße,

ChrisD