neues Modul: SIEMENS Anbindung / S7 / Siemens Logo

fu_zhou · 30 Januar 2015, 18:39:20

Hallo zusammen,

bei mir hat der Umstieg auf Anhieb geklappt und es ist beeindruckend, wie die "Eventlast" (s. Event Monitor) runtergeht, wenn man das Attribut "event-on-change-reading state:0.01" (oder state:0.1) nutzt.

ABER: ich kann bestätigen, dass event-min-interval nicht funktioniert. Ich habe event-min-interval mal mit einem Slider probiert (also reinen FHEM-Mitteln), da hat es auch nicht funktioniert.

Und vorhin ist mal die Kommunikation ausgefallen, da steht im Log:

Code Auswählen

2015.01.30 19:15:15 3: Temp_AU_Web S7_AWrite_Set: write buffer length error
2015.01.30 19:15:15 3: PCS_7 disconnected
2015.01.30 19:15:15 2: PCS_7 S7 disconnected
2015.01.30 19:15:16 3: PCS_7 S7_connect: connect to PLC with maxPDUlength=240
2015.01.30 19:15:17 2: PCS_7 S7_connect: allready connected!
2015.01.30 19:15:18 2: PCS_7 S7_connect: allready connected!
2015.01.30 19:20:31 1: PERL WARNING: Use of uninitialized value $buffer in addition (+) at ./FHEM/44_S7.pm line 577

Nach einem Neustart von FHEM war die Welt wieder in Ordnung und ist es geblieben. Reproduzieren konnte ich den Fehler bisher nicht.

charlie71 · 30 Januar 2015, 22:14:20

Hallo rhonline,

also die config ist aus meiner Sicht OK.
Die Fehlermeldung besagt, dass ein Fehler beim Übertragen eines ISO Paketes aufgetragen ist (Länge zu kurz oder zu lang).
Soweit ich weiss, hat das Schreiben mit einer S300 funktioniert.
Setzt du das Modul auf einer raspberry PI Plattform ein?

lG
Charlie71

Zitat von: rhonline am 30 Januar 2015, 17:07:33
Hallo zusammen,

ich stecke wieder in einer Misere und ich hoffe ihr könnt helfen.
Habe auf V2.3 hochgerüstet.
Lesen aus der CPU klappt.
Schreiben leider nicht.
Auch schon bei der V2.2 nicht.
....

John · 30 Januar 2015, 23:28:22

@charlie71 und @fu_zhou

Zitat
ABER: ich kann bestätigen, dass event-min-interval nicht funktioniert. Ich habe event-min-interval mal mit einem Slider probiert (also reinen FHEM-Mitteln), da hat es auch nicht funktioniert.

Das habe ich schon vermutet.

event-min-interval, ebenso wie event-on-change-reading sind integraler Bestandteil von FHEM und werden automatisch
bei einem Update eines Readings berücksichtigt.

Nochmal zur Funktionsweise:

Code Auswählen

attr aussentemp event-on-change-reading .*:0.5
attr aussentemp event-min-interval .*:300

Reading wird beschrieben
wenn der Name mit dem bei event-min-interval matched und seit dem letzten Update mehr als 300 Sekunden vergangen sind
dann wird ein Event in jedem Fall gefeuert.
Wenn der Name matched und der Wert des Readings sich um mindestens 0.5 zum Alt-Wert (Wert beim vorherigen Event) geändert hat, dann wird
ein Event gefeuert

Wenn aber der erste Schritt fehlt, (Aktualisierung des Readings), können die beiden folgende Schritte niemals
zur Ausführung kommen.

John

John · 30 Januar 2015, 23:34:58

@alle S7-Fans

Charlie71 hat sich mit der nativen Implementierung der S7-Anbindung einen großen Brocken vorgenommen.

Ja er bekommt von den einzelnen Unterstützung, aber gefragt ist vor allem Perl-Programmierung.

Jeder der ein S7-Programm oder Logo-Programm erstellen kann, kann auch Perl lernen.

Nur so eine Idee für das kommende Wochenende.

John

fu_zhou · 31 Januar 2015, 07:15:23

@John,

die Aktualisierung des Readings funktioniert. Der S7-Analogwert wird ja sekündlich aus dem DB gelesen und auch nur dann ins Log-File geschrieben, wenn die event-on-change-reading Bedingung erfüllt ist. Am Event-Monitor sieht man das auch sehr gut. Ich habe mal das event-on-change-reading sehr hoch gesetzt (Event wird also nie ausgelöst) und event-min-interval auf 5 Sekunden. Trotzdem funktioniert es bei dem S7-ARead nicht. Kann es sein, dass event-on-change-reading "höher prior" ist? In der device Ansicht unter Readings ändert sich state nur, wenn die event-on-change-reading Bedingung erfüllt ist. Das hieße ja, dass wenn innerhalb des min-intervals die change-reading Bedingung nicht einmal erfüllt wird, der Timer nicht funktioniert?

Mit deiner Erklärung unten habe ich, glaube ich, verstanden, warum es beim Slider nicht funktionieren kann: Solange der Slider nicht bedient wird, wird kein Reading beschrieben, daher zählt auch der Timer nicht los. Ist das so korrekt?
Was passiert aber, wenn ich den Slider einmal bedient habe? Dann müsste der Timer doch wenigstens einmal runterzählen und den Wert ins Log schreiben, der beim Ablauf des Timers aktuell ist. Dann läuft der Timer erst wieder nach dem nächsten Bedienen des Sliders los?
Aber, wie gesagt, der S7-Wert ändert sich sekündlich. Habe ich hier noch einen Denkfehler?

Danke und Gruß,

fu_zhou

rhonline · 31 Januar 2015, 07:20:25

Hallo charlie71,

Ja, fhem habe ich jetzt auf einem RasPi laufen.
Ich versuche es heute auch mal auf der FB zum Leben zu erwecken.

Fehler findet man am schnellsten, wenn sie mitwandern

Zitat von: charlie71 am 30 Januar 2015, 22:14:20
Hallo rhonline,

also die config ist aus meiner Sicht OK.

Die Fehlermeldung besagt, dass ein Fehler beim Übertragen eines ISO Paketes aufgetragen ist (Länge zu kurz oder zu lang).
Soweit ich weiss, hat das Schreiben mit einer S300 funktioniert.
Setzt du das Modul auf einer raspberry PI Plattform ein?

lG
Charlie71

Nachtrag :
Habe mal gerade ins log-Buch geschaut

Code Auswählen

  

2015.01.31 00:01:58 3: S7300 S7_ReadBlockFromPLC ReadArea error: 3=A timeout occurred waiting a reply.
2015.01.31 00:01:58 2: S7300 S7 disconnected
2015.01.31 00:02:01 3: S7300 S7_connect: connect to PLC with maxPDUlength=240
2015.01.31 00:40:28 3: S7300 S7_ReadBlockFromPLC ReadArea error: 3=A timeout occurred waiting a reply.
2015.01.31 00:40:28 2: S7300 S7 disconnected
2015.01.31 00:40:31 3: S7300 S7_connect: connect to PLC with maxPDUlength=240
2015.01.31 01:38:09 3: S7300 S7_ReadBlockFromPLC ReadArea error: 3=A timeout occurred waiting a reply.
2015.01.31 01:38:09 2: S7300 S7 disconnected
2015.01.31 01:38:12 3: S7300 S7_connect: connect to PLC with maxPDUlength=240
2015.01.31 02:30:54 3: S7300 S7_ReadBlockFromPLC ReadArea error: 3=A timeout occurred waiting a reply.
2015.01.31 02:30:54 2: S7300 S7 disconnected
2015.01.31 02:30:57 3: S7300 S7_connect: connect to PLC with maxPDUlength=240

rhonline · 31 Januar 2015, 11:14:49

Hallo zusammen,

ich habe jetzt mal fhem mit 44_S7 auf der FB reaktiviert.
Gleiche Effekte.
Ich habe auch mal die Überwachungszeit im Modul S7_Client hochgesetzt. Kein Erfolg.
Da der Fehler mitgewandert ist, müsste es bei mir ja an der S7 liegen,
außer es fällt jemandem noch was anderes ein.
Von daher würde mir nur ein Downgrade auf V1.15 helfen, da hat's ja funktioniert.

Hier nochmal das log der FB im Fehlerfall, also wenn ich ein Bit übertragen möchte.

Code Auswählen

2015.01.31 11:12:22 3: S7300 S7_WriteBlockToPLC WriteArea error: 8=Malformed PDU supplied.
2015.01.31 11:12:22 2: S7300 S7 disconnected
2015.01.31 11:12:22 3: S7300 disconnected
2015.01.31 11:12:22 2: S7300 S7 disconnected
2015.01.31 11:12:23 3: S7300 S7_WriteBlockToPLC: PLC is not connected 
2015.01.31 11:12:23 3: S7300 disconnected
2015.01.31 11:12:23 2: S7300 S7 disconnected
2015.01.31 11:12:24 3: S7300 disconnected
2015.01.31 11:12:24 2: S7300 S7 disconnected
2015.01.31 11:12:25 3: S7300 S7_connect: connect to PLC with maxPDUlength=240
2015.01.31 11:12:25 2: S7300 S7_connect: allready connected!

rhonline · 31 Januar 2015, 11:44:56

Hallo,

ich habe jetzt mal nach dem Error-Code gesucht.
Da gibt es im Netz verschiedene Zuordnungen

Auszug aus dem S7_Client Modul :

Code Auswählen

use constant  errTCPConnectionFailed => 0x0001;
use constant  errTCPConnectionReset  => 0x0002;
use constant  errTCPDataRecvTout     => 0x0003;
use constant  errTCPDataSend         => 0x0004;
use constant  errTCPDataRecv         => 0x0005;
use constant  errISOConnectionFailed => 0x0006;
use constant  errISONegotiatingPDU   => 0x0007;
use constant  errISOInvalidPDU       => 0x0008;

use constant  errS7InvalidPDU        => 0x0100;
use constant  errS7SendingPDU        => 0x0200;
use constant  errS7DataRead          => 0x0300;
use constant  errS7DataWrite         => 0x0400;
use constant  errS7Function          => 0x0500;

use constant  errBufferTooSmall      => 0x0600;

Im Netz habe ich aber auch folgende Zuordnung gefunden : Quelle : http://snap7.sourceforge.net/moka7.html

errISOInvalidPDU 0x0006 Malformed PDU supplied.
errISOConnectionFailed 0x0007 ISO connection failed.
errISONegotiatingPDU 0x0008 ISO PDU negotiation failed.

Danach würde 0x0008 auf eine negative Rückmeldung des Partners (S7) in Bezug auf die PDU-Länge bedeuten.
Die PDU-Länge ist ja weiterhin "240" bei der S7-300, oder ?

John · 31 Januar 2015, 11:52:47

Hallo rhonline,

verwende doch mal den angehängten Client. (Demo von Snap7)
Dieser gibt die verhandelte PDU-Size aus.

Bei einer S7 scheint mir die PDU von 240 viel zu klein zu sein.

John

John · 31 Januar 2015, 11:54:31

Ich hab mir nochmal das Thema zu event-min-interval angesehen.

Ich glaube das ist ein Fehler in FHEM, ich werde das Problem im Developer-Forum vorstellen, um dort eine Klärung zu finden.

John

rhonline · 31 Januar 2015, 12:07:57

Hallo John,

habe ich gemacht....
Rückmeldung "240" !!!!

PS: mit dem Tool kann ich auch in die S7 schreiben!

Zitat von: John am 31 Januar 2015, 11:52:47
Hallo rhonline,

verwende doch mal den angehängten Client. (Demo von Snap7)
Dieser gibt die verhandelte PDU-Size aus.

Bei einer S7 scheint mir die PDU von 240 viel zu klein zu sein.

John

John · 31 Januar 2015, 12:13:18

Vergleiche mit Wireshark die Connect-Sequenz von Charlie's Modul und vom Demo-Client.

Das wird Charlie gute Hinweise liefern.
John

charlie71 · 01 Februar 2015, 16:47:09

Hallo Leute,

ich hab mal folgendes Testsetup für den connection Test aufgesetzt:
* nativer perl client:
* lib no dave client:
(Testpartner Logo7)

Beide lesen ein Byte und schreiben ein Byte.
Mit Hilfe von Wire shark habe ich die beiden Kommunikationen protokolliert und verglichen.
Meiner Meinung nach gab es nur unwesentliche Abweichungen. Nichts desto trotz habe ich den perl client an den lib nodave client angepasst.
Es werden nun die selben Daten auf TCP Ebene übertragen.

Der aktualisierte Client im Anhang. Bitte tauschen und dann bitte ein kurzes Feedback.
lG
Charlie71

pc1246 · 01 Februar 2015, 19:43:42

Hallo Charlie
Habe den neuen client installiert! Test folgt sofort! Ich habe uebrigens schon ewig diese Fehlermeldung "Undefined subroutine &main::S7_Client_Initialize called at fhem.pl line 2052. " beim Aktualisieren des 44_S7_Clients!
Bit setzen geht! Analog schreiben und lesen geht auch!

Ok: Jetzt habe ich die DEF aktualisiert! PDU 960 wurde eingetragen! Danach kam disconnected, dann ging bit setzen nicht mehr! dann wieder connected PDU wieder 240, aber analog lesen ist jetzt aus!
Nach Neustart ist alles wieder gut! Ich hatte aber auch nicht gespeichert!

WinLC: Lesen geht! Schreiben nicht! Auch nicht wenn nur eine Steuerung definiert!

Das Problem mit zwei SPSen ist immer noch da! Ich habe jetzt gesehen, dass gelesene Worte in beiden Steuerungen landen, zumindest auf fhem! Scheint aber auch nur bei der Aenderung auf der 2ten zu passieren!
Das war aber schon lange meine Vermutung, dass da mit mehreren etwas schief laeuft!

Gruss Christoph

alfonsmoeller · 01 Februar 2015, 20:13:02

Hallo charlie71,
auf die Schnelle kann ich nur berichten S7-315 ok.
Mit einer RTX keine Änderung. Lesen ok, Schreiben geht nicht!

Das ist jetzt doppelt so viel:
2015.02.01 20:00:37 3: PCS_7 S7_connect: connect to PLC with maxPDUlength=480

m.f.G. Alfons