neues Modul: SIEMENS Anbindung / S7 / Siemens Logo

alfonsmoeller · 19 Februar 2015, 19:56:42

Hallo Hartman85,
das sieht so aus als ob charlie71 da gefordert ist. Genau das gleiche Bild zeigt sich mit WinLC und RTX.
Das gleiche Problem hatte ich auch schon mit 44_S7_DWrite bei einer älteren Version.

Deine Netzwerkanbindung würde mich noch interessieren. Wenn ich das noch richtig weiß hast Du
ein 315PN/DP.

m.f.G. Alfons

Hartman85 · 19 Februar 2015, 20:04:40

Ja genau Hab ne CPU 315-2 PN/DP die im Keller sich befindet.. diese Sps ist über ein Switch welcher über DLAN mit dem Router im Arbeitszimmer verbunden ist angeschlossen. Der FHEM Server ist ein Raspberry welcher sich ebenfals im Schrank von der SPS befindet. Auch diesser ist dort an das Switch angeschlossen.Die Visualisierung erfolgt über ein Tablet welches sich im Wohnzimmer mit Wlan anmeldet..

IP:
SPS 192.168.0.100
Tablet 192.168.0.19
FHEM 192.168.0.33

MFG

Hartman85

charlie71 · 19 Februar 2015, 20:48:35

Hallo Leute,

ich bitte um ein wenig Geduld, ich dieser Woche habe ich nur bedingt für diese Projekt Zeit (Urlaub).
Ich denke das es bei der 315 ein Problem gibt und somit AWrite nicht funktioniert. Wenn wir Glück haben ist das auch die Ursache von den Problemen mit der WinLC.

Ich habe den FHEM Code soweit mit libnodave und snap7 verglichen, konnte jedoch keinen signifikanten Unterschied feststellen.

Ich benötige nun EURE Hilfe das Problem zu fixen:
a) einen Wireshark Mitschnitt mindestens eines funktionierten Schreibvorgang (am besten ein DWORD) auf die S315.
b) einen Wireshark Mitschnitt mindestens eines funktionierten Schreibvorgang (am besten ein DWORD) auf die WinLC.
Bitte auch auf der SPS nachschauen ob der Schreibbefehl auf der SPS erfolgreich war, obwohl FHEM einen Fehler meldet.

Bitte um Bestätigung ob soweit ARead, DRead und DWrite auf S315 und WinLC funktioniert.
Danke und lG
Charlie71

Hartman85 · 19 Februar 2015, 21:00:18

Ja helfe dir gerne..bin noch Unterwegs. .kann nir soviel sagen das DRead.DWRITE und AREAD einwandfrei funktionieren...werde dann morgen mal einen Mitschnitt machen und hier posten..

Hartman85 · 20 Februar 2015, 21:54:38

Hi folgendes Problem dadurch das der FHEM auf nem Raspberry liegt kann ich keine Nachrichten per Wireshark auswerten bzw Aufzeichen..Gucke aber morgen mal ob ich das Provisorisch aufnem Windows Pc zum Laufen bekomme..melde mich dann nochmal

LG

Hartman85

charlie71 · 21 Februar 2015, 14:12:30

Hallo,

für die Fehleranalyse bei der 315 benötige ich einen funktionierenden Kommuniktionsmitschnitt der SW mit der 315.
Die SW sollte auf jeden Fall nicht das FHEM Modul sein, da ja hier ein Fehler vorhanden ist.

Der Plan ist, dass ich mit den Kommunikationsmitschnitt Unterschiede zu der Kommunikation des FHEM feststelle und dann das FHEM Modul anpassen kann.

lG
Charlie71

PS: Wurde die FW der 315 auf die letzte Version aktualisiert?

fu_zhou · 21 Februar 2015, 17:45:18

Hallo zusammen,

ich habe morgen erst wieder Zugriff auf mein System. Ich habe u.a. eine 6ES7 315-2EH14-0AB0 V3.2 (315-2 PN/DP) im Einsatz, mit der das Modul im vollem Umfang funktioniert.
Ich werde morgen mal versuchen, erstmalig mit Wireshark zu arbeiten. Dazu werde ich im SIMATIC Manager über Variablentabelle die selben Adressen im DB beschreiben, wie AWrite (Float) und mit Wireshark protokolllieren. Das selbe mache ich dann noch einmal mit FHEM. Die beiden Protokolle sollte sich in meinem Fall ja nicht unterscheiden, da das Modul ja funktioniert. Vielleicht hilft mein Test und die Protokolle aber, das Problem mit der Soft SPS und bei Hartman85 zu finden.

Gruß, fu_zhou

Hartman85 · 21 Februar 2015, 19:06:37

Ja das Wäre Cool hab probeweise mal versucht über eine Cp die Komunikation zuschaffen aber bisher nix neues alles bis auf AWRITE gehen

alfonsmoeller · 21 Februar 2015, 21:25:01

Hallo, es tut mir leid das ich im Moment nicht zur Verfügung stehe. Gebt mir 1 Woche Zeit, dann bin ich wieder z.Haus.
Wenn alles gut läuft am Mittwoch. Habe S7-315, WinLC und RTX. Könnte alle Test's machen.
m.f.G. Alfons

fu_zhou · 22 Februar 2015, 14:44:12

Auf dem Pi benutze ich die Perl-Version, die über "sudo apt-get install perl ..." installiert wird = 5.14.2 (s. /usr/lib/perl).
Für den Windows-Rechner habe ich mir also Strawberry-Perl in der dazu passensten Version (5.14.2.1) als 64bit Portable heruntergeladen. FHEM ist die V5.6 mit den aktuellen Updates.
FHEM entpacken, Strawberry Perl entpacken und in das FHEM Verzeichnis verschieben, sieht dann z.B. so aus wie im Screenshot.
=> FHEM läuft schon mal auf dem Windows Rechner. Ich starte über eine Batch-Datei mit folgendem Inhalt:

Code Auswählen

d:\FHEM\fhem-5.6\perl\bin\perl.exe d:\FHEM\fhem-5.6\fhem.pl fhem.cfg
Dann noch im Browser "localhost:8083" eingeben und die Web-Oberfläche erscheint.

S7-Module dazu kopieren und dann:

Erste Hürde:
Um das S7-Modul unter Windows zum Laufen zu bekommen, muss das "Switch.pm" Modul hinzugefügt werden. Dieses ist ersetzt worden durch "give/when", so dass "Switch.pm" nicht mehr standardmäßig dabei ist.

Code Auswählen

Switch - A switch statement for Perl, do not use if you can use given/when
Ich habe "Switch.pm" hier gefunden:

Code Auswählen

http://search.cpan.org/CPAN/authors/id/C/CH/CHORNY/Switch-2.17.tar.gz
Die "Switch.pm" aus dem Archiv nach "/perl/lib" kopieren und schon können die S7 Module geladen werden.

Dwrite und AWrite funktionieren unter Windows leider nicht, hier das Log-File

Code Auswählen

2015.02.22 16:12:21 0: Server started with 12 defined entities (version $Id: fhem.pl 8030 2015-02-18 17:32:56Z rudolfkoenig $, os MSWin32, user User, pid 7448)
2015.02.22 16:12:27 3: 315 S7_connect: connect to PLC with maxPDUlength=240
2015.02.22 16:13:14 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at FHEM/44_S7_Client.pm line 931.
2015.02.22 16:13:14 3: 315 S7_WriteBitToPLC WriteArea error: 4=Ethernet driver returned an error sending the data
2015.02.22 16:13:14 2: 315 S7 disconnected
2015.02.22 16:13:14 1: PERL WARNING: Argument "315 S7_WriteBitToPLC WriteArea error: 4=Ethernet driver ..." isn't numeric in numeric eq (==) at ./FHEM/44_S7_DWrite.pm line 232.
2015.02.22 16:13:14 3: 315 disconnected
2015.02.22 16:13:14 2: 315 S7 disconnected
2015.02.22 16:13:17 3: 315 S7_connect: connect to PLC with maxPDUlength=240
2015.02.22 16:13:17 2: 315 S7_connect: allready connected!
2015.02.22 16:13:32 3: 315 S7_WriteBlockToPLC WriteArea error: 4=Ethernet driver returned an error sending the data
2015.02.22 16:13:32 2: 315 S7 disconnected
2015.02.22 16:13:32 1: PERL WARNING: Argument "315 S7_WriteBlockToPLC WriteArea error: 4=Ethernet drive..." isn't numeric in numeric eq (==) at ./FHEM/44_S7_AWrite.pm line 243.
2015.02.22 16:13:32 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 127) line 1.
2015.02.22 16:13:32 3: eval: {
fhem "set Temperaturkorrektur_315 ".ReadingsVal("Temperaturkorrektur_315_Knob","state","0");
}
2015.02.22 16:13:33 3: 315 disconnected
2015.02.22 16:13:33 2: 315 S7 disconnected
2015.02.22 16:13:35 3: 315 S7_connect: connect to PLC with maxPDUlength=240
2015.02.22 16:13:36 2: 315 S7_connect: allready connected!

DRead und ARead funktioniert. Wenn ich über den Pi mit DWrite und AWrite auf die S7-315 schreibe, werden im Windows-FHEM die Werte korrekt aktualisiert und angezeigt.

fu_zhou · 22 Februar 2015, 17:21:58

So, habe jetzt auch mit Wireshark experimentiert unter Nutzung des S7-Comm Plugins.

Ich habe mit der Variablentabelle im S7-Manager das Doppelwort 0 (Float) im DB72 beschrieben, also die Adresse, die ich mit AWrite vom Pi erfolgreich beschreiben kann und die ich von Windows mit FHEM nicht beschrieben bekomme.

Da die Variablentabelle während meines Versuchs die ganze Zeit online war, ist das Wireshark-Protokoll relativ groß, glaube ich.

Ich habe auch noch mal einen FHEM-Mitschnitt beigefügt, ich weiß nicht, ob der irgendwie hilft.

Charlie, melde dich jederzeit mit weiteren Test-Aufträgen!

Hartman85 · 22 Februar 2015, 17:26:53

Vielen Dank hoffe damit kann was erreichen..tut mir leid das ich die Hardware nicht habe um den Versuch selber durch zuführen..deshalb danke das du das gemacht hast..

Lg
Hartman85

fu_zhou · 22 Februar 2015, 17:52:21

Hallo Charlie,

ich habe jetzt noch einmal die Snap7 Client Demo für Windows verwendet, dabei ist ein wesentlich kleineres und daher wahrscheinlich übersichtlicheres Wireshark-Protokoll herausgekommen.

Ich habe mit dem Client 99.9 und anschließend 88.8 in den DB72.DBD0 (float) geschrieben (vielleicht auch anders herum). Die Hex-Werte in den Bytes sehen wie folgt aus:
99.9: Byte 0=42, Byte 1=C7, Byte 2=CC, Byte 3=CD
88.8: Byte 0=42, Byte 1=B1, Byte 2=99, Byte 3=9A

Ich habe das ganze noch einmal mit der Variablentabelle online im Simatic Manager nachvollzogen und die Werte kommen im DB an.

charlie71 · 23 Februar 2015, 08:36:47

Hallo Leute,

ich hab mal eine Spur wo das Problem liegen könnte.
Folgende Fragen an die 315 Besitzer
1) Bitte um Bestätigung, dass DWrite funktioniert.
2) Bitte um Bestätigung, dass u8 AWrite (SPS Datentyp BYTE) funktioniert.
3) Bitte um Bestätigung, dass u16,s16,u32,s32 und float AWrite (SPS Datentypen WORD, INT, DWORD, DINT, REAL) nicht funktionieren.

Danke und lG
Charlie71

fu_zhou · 23 Februar 2015, 10:11:45

Hallo Charlie,

bei mir funktioniert DWrite und AWrite (Float) zur S7-315 mit dem Raspberry Pi, unter Windows funktioniert DWrite und AWrite (Float) nicht (s. Log im Post #504). Es kommen hier auch tatsächlich keine Werte im DB an.
Die anderen Datentypen werde ich heute Abend mal probieren.

Ich nutze die V2.8

Gruß und Danke!

fu_zhou