neues Modul: SIEMENS Anbindung / S7 / Siemens Logo

[GeRei77]

Hallo Charlie71,

Habe gestern Abend die Verbindung hinbekommen 

Weiß aber nicht 100 prozentig woran es lag. Hab nochmal die Dateien 44_S7* eingespielt, rechte nochmal vergeben und RPi neu gestartet.
Fhem konnte dann eine Verbindung zu einem Logo herstellen.
Bei der anderen habe ich unter Servereinstellungen den Remote TSAP auf 01.00 gestellt und war danach auch verbunden.

Bin jetzt mal zufrieden und hoffe demnächst wenn ich wieder mehr Zeit habe mit dem programmieren zu beginnen.

Vielen Dank an alle

[goerdi]

Hallo !

Ich bin auf Jessie umgestiegen, und dabei fiel mir auf das sie Systemlast mit diesem Modul hoeher ist als mit den "Logo Only Modul"
Mir viel das am SVG Plot auf welcher die RPi Frequenz auszeichnet. beim "alten" kam die Freq. nur recht selten auf max... aber seit der Umstellung ist dies ein durchgängiger Balken.
Kann das einer bestätigen ?
Gibts ne Möglichkeit die Last zu senken ?

Gruss Gerd

[davipet]

Moin,

ich habe das Modul schon eine Weile in Betrieb. Bis vor Kurzem funktionierte alles prima. Neuerdings sieht mein Log so aus:

Code Auswählen Erweitern


2015.11.30 10:38:22 3: S7_300 S7_connect: connect to PLC with maxPDUlength=240
2015.11.30 10:38:49 3: S7_300 S7_ReadBlockFromPLC ReadArea error: 3=A timeout occurred waiting a reply.
2015.11.30 10:38:49 2: S7_300 S7 disconnected
2015.11.30 10:38:52 3: S7_300 S7_connect: connect to PLC with maxPDUlength=240
2015.11.30 10:39:19 3: S7_300 S7_ReadBlockFromPLC ReadArea error: 3=A timeout occurred waiting a reply.
2015.11.30 10:39:19 2: S7_300 S7 disconnected
2015.11.30 10:39:22 3: S7_300 S7_connect: connect to PLC with maxPDUlength=240
2015.11.30 10:41:47 3: S7_300 S7_ReadBlockFromPLC ReadArea error: 3=A timeout occurred waiting a reply.
2015.11.30 10:41:47 2: S7_300 S7 disconnected
2015.11.30 10:41:50 3: S7_300 S7_connect: connect to PLC with maxPDUlength=240
2015.11.30 10:42:19 3: S7_300 S7_ReadBlockFromPLC ReadArea error: 3=A timeout occurred waiting a reply.
2015.11.30 10:42:19 2: S7_300 S7 disconnected
2015.11.30 10:42:22 3: S7_300 S7_connect: connect to PLC with maxPDUlength=240
2015.11.30 10:42:49 3: S7_300 S7_ReadBlockFromPLC ReadArea error: 3=A timeout occurred waiting a reply.


Das Log ist quasi voll damit...

Geändert hat sich eigentlich nichts - es wurde nur immer mal ein paar mehr Daten die ich lese/schreibe.

Mein System ist FHEM 5.6 auf RaspberryPi 2. Das Modul ist auf 2.10 und an eine S7 300 2DP mit CP 343-1 angebunden.
Wo kann ich ansetzen den Fehler zu suchen?

Danke!

Gruß

David


EDIT: Kann es an der Menge der Daten die gleichzeitig gelesen werden sollen liegen?
Manche Werte möchte ich nur 1x am Tag aktualisieren. Wie stelle ich es an, das nur zu einer bestimmten Zeit der Wert gelesen wird?

[charlie71]

Hallo goerdi,

wenn du nichts an den Standardeinstellung änderst, wird jede Sekunde alle daten von der SPS eingelesen und die logischen Clients (DRead ,.... ) aktualisiert.
Die logischen Clients versenden dann auch bei jeden Update ein notify (unabhängig ob sich der Status geändert hat oder nicht).
Das ist ein ganz normales verhalten in FHEM. Damit jedoch nicht das System unnötige notifys verschickt kannst du dass über die standard Attribute event-on-change-reading und event-min-interval beeinflussen.

Hier ein Beispiel aus meiner Config:
Es wird der Ausgang für einen Rolloausgang gemonitort. Ein Notify soll nur dann geschickt werden wenn sich der status ändert aber es soll alle 10 Minuten auf jeden Fall ein Notify geschickt werden:

Code Auswählen Erweitern

define L1_Q15 S7_DRead Q15
attr L1_Q15 IODev logo
attr L1_Q15 alias Rollo auf
attr L1_Q15 devStateIcon Ein:li_wht_on Aus:li_wht_off
attr L1_Q15 event-min-interval .*:600 #<--- Alle 10 min ein status update schicken
attr L1_Q15 event-on-change-reading state #<--- nur wenn sich der Status geändert hat dann ein Notify schicken
attr L1_Q15 eventMap on:Ein off:Aus


Noch ein Beispiel für meinen Temperatursensor, der wird nur dann im FHEM aktualisiert wenn sich die Temperatur um 0.5°C geändert hat

Code Auswählen Erweitern

define innentemp S7_ARead db 0 796 u16
attr innentemp IODev logo3
attr innentemp alias Innentemperatur
attr innentemp event-min-interval .*:600 #<--- Alle 10 min ein status update schicken
attr innentemp event-on-change-reading .*:0.5  #<--- nur wenn sich die Temperatur um 0.5°C geändert hat dann ein Notify schicken
attr innentemp icon icoTempHausEG
attr innentemp multiplicator 0.1
attr innentemp stateFormat {sprintf("%.1f",ReadingsVal("innentemp","state",0))." °C"}

wenn du das konsequent umsetzt solltest die Systemlast stark zurück gehen.
Du kannst die Aufrufdauer aller Module mit "apptime" prüfen.

lg
Charlie71

[charlie71]

Hallo davipet,

Vermutlich liegt es nicht an der Datenmenge, wieviele Daten liest du den von der SPS ein (#digitale Datenpunkte, # analoge Datenpunkte)?. Was sagt den apptime?

Theoretisch besteht die Möglichkeit mehre Connections zur selben SPS zu machen über den Parameter Intervall (siehe Wiki) kannst Du steuern wie oft die Wert von der SPS gelesen werden sollen. Aber Vorsicht nicht alle SPS unterstützen mehrere simultane connection zum selben client (meine Logo7 mag das nicht und lässt nur eine Verbindung zu)

Versuch einfach das Modul neu zu installieren, weiss nicht warum aber mehrere haben damit das Problem gelöst

lG
Karl

[charlie71]

Hallo Leute,

ich bin gerade (wieder) dabei das Modul ein wenig umzubauen.
Der Focus ist dabei definitiv auf Geschwindigkeit.
Dabei hat sich die Geschwindigkeit von V2.9 auf V2.11 ungefähr um den Faktor 8 gesteigert (zumindest bei meiner Config)
Ich werde in einen der nächsten Versionen auf nonBlocking calls umsteigen das sollte noch ein wenig Speed bringen.

Im Anhang eine Testversion (V2.11) ist wirklich nur zum testen (dh nicht für den Produktivbetrieb) gedacht.
In dieser Version habe ich die nonBlocking Calls vorbereitet und diverse caches eingebaut (--> modul ist wieder schneller)

Außerdem habe ich ein Problem gefixed, das sich negativ beim modul reload ausgewirkt hat (das modul ist lt. apptime mit jedem reload langsamer geworden erst mit einem kompletten shutdown reload hat das behoben).

Bitte das Modul testen und bei Problemen mir ein Feedback schicken.

Release Notes:
V2.11
* (fix) memory allocation fix during shutdown/restart sequence
* preperation  for non blocking calls: job caching, clients chache --> speeds up the module

[davipet]

Hallo Karl,

Der CP 343-1 erlaubt bis zu 12 Verbindungen. 1 Nutzt mein WinCC-Server und 1 das FHEM. Also sind theoretisch 10 weitere Verbindungen möglich. Auch vom selben Client.
Wenn ich dich richtig verstehe kann ich eine Verbindung mit einem sehr großen Intervall für die sehr langsamen Werte anlegen und per

Code Auswählen Erweitern

attr <name> IODev <weitere_Verbindung>
mit der Variable Verknüpfen. Das ist ein Ansatz mit dem ich leben kann. Ich probiere das mal aus.

Derzeit lese/schreibe ich 24Digitale und 9 analoge Werte. (Habe zum Test schon ~50 Analoge auskommentiert)
Das ist nicht viel denke ich. Der Fehler kommt aber noch immer.

Mit "Modul neu installieren" meinst du die 44_S7_*.pm überschreiben?

An dieser Stelle mal ein dickes Dankeschön für das Modul! Ich finde es grandios, dass Leute wie Du in ihrer Freizeit derart geniale Dinge schaffen und vor allem über einen sehr langen Zeitraum beispiellos supporten. Ich weiß das zu schätzen und profitiere sehr davon. Also, vielen Dank!

Gruß

David

[charlie71]

Hallo davipet,

ich denke hier gibt es mehrere Missverständnisse bzw ich bin mir nicht sicher ob es klar ist

1) Eine SPS mit mehreren Connections
Ein Beispielcode:

Code Auswählen Erweitern

# S7 Kommunikation mit 1 CPUs und 2 verschiedenen Intervallen
#erste Connection aktuallisiert jede Sekunde
define 317fast S7 192.168.1.101 0 2 1
attr 317fast room System

#zweite Connection aktuallisiert alle 5 minuten
define 317slow S7 192.168.1.101 0 2 300
attr 317slow room System

# FHEM Taster an 317
define Taster_317 S7_DWrite db 23 0.0
attr Taster_317 IODev 317fast
attr Taster_317 devStateIcon .*:toggle:TRIGGER
attr Taster_317 event-on-change-reading state
attr Taster_317 group Licht
attr Taster_317 room Keller

# Rückmeldung ob 317 DO gesetzt hat
define Rueckmeldung_317 S7_DRead db 21 0.0
attr Rueckmeldung_317 IODev 317slow
attr Rueckmeldung_317 event-on-change-reading state
attr Rueckmeldung_317 group Licht
attr Rueckmeldung_317 room Keller

2)Datenmenge
Es ist tatsächlich nicht viel. Ein kompletter Einlesevorgang aller Werte inklusiver aller Notifiys in FHEM sollte < 80ms sein

3)Neuinstallieren
ja einfach nur überschreiben.

lG
Charlie71

[davipet]

Hi,

Code Auswählen Erweitern

# S7 Kommunikation mit 1 CPUs und 2 verschiedenen Intervallen
#erste Connection aktuallisiert jede Sekunde
define 317fast S7 192.168.1.101 0 2 1
attr 317fast room System

#zweite Connection aktuallisiert alle 5 minuten
define 317slow S7 192.168.1.101 0 2 300
attr 317slow room System

# FHEM Taster an 317
define Taster_317 S7_DWrite db 23 0.0
attr Taster_317 IODev 317fast
attr Taster_317 devStateIcon .*:toggle:TRIGGER
attr Taster_317 event-on-change-reading state
attr Taster_317 group Licht
attr Taster_317 room Keller

# Rückmeldung ob 317 DO gesetzt hat
define Rueckmeldung_317 S7_DRead db 21 0.0
attr Rueckmeldung_317 IODev 317slow
attr Rueckmeldung_317 event-on-change-reading state
attr Rueckmeldung_317 group Licht
attr Rueckmeldung_317 room Keller

Ja, so habe ich es verstanden und auch umgesetzt.
Es kommen bei beiden Verbindungen leider schon Verbindungsabbrüche.

Ich spiele nachher mal 2.11 ein.

Was mich verwundert ist, dass es eine ganze Weile (Monate) problemlos funktionierte...

apptime gibt folgendes zurück:

Code Auswählen Erweitern


name; function; max; count; total; average; maxDly
tmr-S7_GetUpdate; HASH(0x3171c40); 1847; 21; 30754; 1464.48; 48; HASH(S7_300_2)

Gruß

David

[charlie71]

Hallo David,

@Verbindungsabbrüche bei 2 Connections zur selben SPS:
Auch bei der Logo hatte ich das selbe Problem.
Vielleicht kannst du bei deiner SPS mehrere Connection mit unterschiedlichen TSAP (Rack/Slot) einrichten.

@Verbindungsabbrüche und Apptime Resultat
Der Funktionsauf für die SPS ist seeeeeeehr langsam (> 1s), was in Summe ein Problem ist, da FHEM eigentlich jede Sekunde (default Einstellung des Moduls) die Werte aktualisieren sollte und das hier nicht mehr ganz klappt.
(Anmerkung: bei ähnlich großen Anzahl an Datenpunkte sollte die apptime average < 80ms sein)

Für die Vorgehensweise benötige ich noch ein paar Infos
1) Was passiert in apptime wenn du das FHEM restartest (shutdown restart) (< V2.11 ist hier noch ein bug drinnen der das System langsamer macht)
2) Was passiert in apptime nach dem du auf 2.11 upgegraded hast?
3) Verwendest du event-on-change-reading und event-min-interval attribute?

lG
Charlie71

[davipet]

Ich habe 2.11 drin. Die zweite Verbindung habe ich wieder entfernt. An der Datenmenge kann es ja eigentlich nicht liegen.

Apptime sagt direkt nach restart:

Code Auswählen Erweitern


name; function; max; count; total; average; maxDly
tmr-S7_GetUpdate; HASH(0x1b94c58); 1838; 11; 17438; 1585.27; 2629 HASH(S7_300_2)


Ja, ich verwende event-on-change-reading recht konsequent. event-min-interval gar nicht.

Ich habe nun meine ursprüngliche Conf wieder am Start. Also lese ich etwa 60 Analoge, Schreibe 10 Digitale und lese 9 Digitale Werte.

Noch ist im Log alles ruhig. Ich update hier wenn sich etwa tut.
Danke!

David

[charlie71]

Hallo David,

versuch mal die MessageLength auf 30 zu beschränken.
Beispiel aus meiner Konfig:

Code Auswählen Erweitern

define mySPS S7 LOGO7 10.0.0.242
attr mySPS MaxMessageLength 30


lG
Charlie71

[davipet]

Moin,

ich habe mit der 2.11 nun keine Verbindungsabbrüche mehr. ~40 Stunden nun stabil! Ich habe an der Config auch nichts weiter geändert.

Die MaxMessageLength ist auch default.

Was ich gemacht habe ist von fu_zhou in Post #484 beschrieben.

in der "44_S7_Client.pm" den Wert "RecvTimeout =>" von 500 auf 3000 gesetzt.

Wenn gewünscht setze ich das nochmal runter um zu verifizieren, dass es daran lag. Sonst lasse ich es jetzt erst mal so.

Danke für die Unterstützung!

David

[charlie71]

Hallo Davipet,

gut das es jetzt funktioniert.

Ich persönlich denke, dass es bei einer stabilen Netzwerkverbindung (dh kein wlan) es nicht notwendig ist, die Timeouteinstellung auf 3s zu erhöhen (ein Messagetransfer zwischen SPS und FHEM dauert üblicherweise <10ms).


Wenn apptime für den Funktionsaufruf "tmr-S7_GetUpdate" einen average Wert > 100ms liefert, denke ich dass die Config noch ein wenig optimiert werden müsste. Es ist für eine verfünftige FHEM performance notwendig dass dieser Wert << 1s ist.
(Ich würde dir auch Vorschläge liefern, wenn du mir deine config per PM zukommen lässt. Anschließend würde ich basierend aus diesen Erfahrungen einen Optimierungsleitfaden im Wiki zu verfassen)

lG
Charlie71

[ClausW]

Hallo zusammen,

von der FHEM Funktionalität auf dem Raspberry Pi in Verbindung mit meiner Siemens Logo 8 bin ich begeistert.

Zum Test der Möglichkeiten habe ich das Modul von Charlie auf dem Raspberry installiert und dann losgelegt.

Mit dem System möchte ich die Rolläden im Haus steuern und habe dafür einen Testschaltplan mit der Software LOGO Comfort entworfen.
Die Steuerung der Rollladenmotore soll dabei über Tastbefehle an Netzwerkeingänge der Logo erfolgen.

Mit dem Befehl:

define Logo76 S7 LOGO8 192.168.1.76
define Motor1 S7_DWrite db 150.1

kann ich auch den Motor schalten.

Da ich aber einen Tastbefehl brauche, habe ich in der WIKI gelesen, dass man über das Attribut "trigger_length" den Schaltbefehl in einen Tastbefehl umwandeln kann.

Nur leider habe ich nirgendwo gefunden, wie ich dieses trigger_length-Attribut als Befehl eingeben kann. Die Beispiele in der FHEM-WIKI zum triggern helfen mir hier überhaupt nicht weiter....

Könnt Ihr mir hier bitte weiterhelfen?
Schon mal besten Dank und viele Grüße
Claus