neues Modul: SIEMENS Anbindung / S7 / Siemens Logo

Begonnen von charlie71, 12 August 2014, 15:33:23

Vorheriges Thema - Nächstes Thema

davipet

#945
Hallo Christoph,

ich denke ja. anbei ein Screenshot.
Erlaubt sind 12, belegt sind 4; frei sind 8
Sollte also eigentlich gehen.


OK, danke. Fhem2Fhem ist ne Möglichkeit.

Gruß

David


EDIT:
OK der erste Screenshot bezieht sich auf alle S7 Verbindungen (also auch Profibus etc.)

Anbei die Diagnose vom CP. Der ist auf 4 Verbindungen beschränkt.
WinCC, TouchPanel, FHEM1 und die Dianose offen = FEHM2 bleibt draußen :(

pc1246

Moin
Ich meine mich zu erinnern, dass man das parametrieren kann. Ist allerdings mit Neustart verbunden!
Gruss Christoph
HP T610
Onkyo_AVR;Enigma2; SB_Server; SB_Player; HM-USB; PhilipsTV; harmony hub; Jeelink mit PCA301; Somfy; S7-300; LGW; HUE; HM-IP auf Charly; div

Tomk

Hallo davipit, ich habe das gleiche Problem ebenfalls mit einer 315-2DP (siehe meine Post auf Seite 62). Allerdings habe ich kein zweites FHEM sondern ein Panel welches ebensfalls über LAN auf die sps zugreift. Ich denke auch hier kommen sich die beiden Teilnehmer in die Quere...

Leider kann ich nicht FHEM2fhem nutzen :-( ich dachte ich hätte das Problem mittels Änderung der Kommunikationsmethode gelöst, aber dem war nicht so... tritt bei mir manchmal jede Minute auf, manchmal ein paar Tage gar nicht.

Tomk

Habe heute nochmal mit den S7 Kommunikationsparametern gespielt... TSAP habe alle möglichen Varianten durchprobiert. Die Einstellung hat meiner Meinung nach überhaupt keinen Einfluss auf die Kommunikationsabrüche.
Hat irgendjemand noch eine Idee? Mir gehen immer wieder Taster Ereignisse und Türkontakte verloren weil die S7 Verbindung in diesem Moment neu aufgebaut wird...

charlie71

Hallo,

aktuell ist die FHEM local TSAP als Konstante im File 444_S7.pm in der Zeile 230:

$LocalTSAP = 0x0100;

Ihr könntet mal versuchen diese zu ändern und mir ein Feedback geben  ob die Änderung was gebracht hat.

lG
Charlie71

Tomk

#950
So ich habe nochmal ein bisschen probiert:
a) in 44_S7.pm habe ich die TSAP (local und partner angepasst). Entsprechend habe ich die S7 Konfiguration angepasst --> Ergebnis die Verbindung kann nicht mehr aufgebaut werden. Was mich wundert ist die max PDU länge wird jetzt auf einmal mit 960 in FHEM angezeigt, obwohl ich daran nichts geändert habe. Vorher stand in den SPS internals immer maxPDUlength 240. die 960 passen jedoch zu den in 44_S7.pm Zeile 233 definierten $PDUlength =0x3c0. Aber warum wurde ohne meine TSAP Änderung die 240 Bytes verwendet?
b) die PDUlength Unstimmigkeit hat mich dazu geführt auch S7 seitig PDUx >240Byte zu erlauben.
Leider war hiermit immer noch kein Verbindungsaufbau möglich.
c) also habe ich in 44_S7.pm die TSAP wieder zurück geändert. S7 Einstellungen wurden beibehalten. --> Ergebnis bislang: Abbrüche deutlich seltener...
Wunderlich hierbei ist, das jetzt die TASP Einstellungen der SPS sich eindeutig unterscheiden von den FHEM einstellungen... daher scheint dies nicht wirklich eine Rolle zu spielen.


Ich werde weiter probieren und berichten.

Tomk

Update: keine Abbrüche mehr seit 8:00 Uhr... die Lösung bei mir in 44_S7_Client die timeout Zeit von 500 auf 750ms geändert...

Kann man das irgendwie als Parameter einbauen?

charlie71

Hallo Tomk,

bereite das Attribut für die nächste Release vor.
Hat jemand sonst noch Wünsche?

Anmerkung zur PDU Size:
Diese wird beim Verbindungsaufbau zwischen den Teilnehmern ausgehandelt und kann sich von der ursprünglichen natürlich unterscheiden.

lg
Charlie71

Tomk

Besten vorab  Charlie!
Bei mir scheint das Problem mit der Timeout Anpassung endgültig behoben zu sein... nun seit ca. 1 Tag keinen Verbindungsabbruch mehr.
Zusammengefasst für alle die das gleiche Problem später nochmal haben: TASP scheint bei der Verbindung FHEM und S7-300 irgendwie keine große Rolle zu spielen. Ich habe in der S7 nun einen ganz anderen Wert. MaxPDU habe ich in der S7 auch größer als 240 Byte erlaubt (ist aber wahrscheinlich auch nicht des Rätsels Lösung). Die Lösung war in 44_S7_Client die Timeout Zeit von 500 auf 750ms zu ändern...

charlie71

Hallo

das neue receiveTimeoutMs Attribut ist via update verfügbar.
default wert 500ms

lG
Charlie71

Tomk

#955
Super, tausend Dank!!!

Scheint zu funktionieren... habe das Attribut auf 750ms gesetzt und hatte heute Nacht keine Timeouts...

Ichirou

Hallo zusammen,

das Modul sieht sehr interessant aus. Bevor ich mir jetzt weiter Gedanken mache, es nutzt die PG/OP Schnittstelle?
Habe hier eine VIPA 313-5BF03 liegen, läuft das?
Falls ja, löst das 2 Dutzend Probleme, angefangen mit einem Gateway auf MPI :)

Grüße

pc1246

Jain
Es wird TCPIP genutzt, ohne Netzwerkanschluss keine Chance!
Gruss Christoph
HP T610
Onkyo_AVR;Enigma2; SB_Server; SB_Player; HM-USB; PhilipsTV; harmony hub; Jeelink mit PCA301; Somfy; S7-300; LGW; HUE; HM-IP auf Charly; div

web.a

Ich nutze eine Vipa 315SB AG12
Funktioniert ohne großen Aufwand. Laut Google hat deine 313 einen RJ45 Netzwerk Anschluss

Gesendet von meinem Xperia ZL mit Tapatalk


Ichirou

Hi,

der RJ45 ist nur für PG/OP und nicht für offene Kommunikation. Ein richtiges Ethernet kriege ich da nicht drüber, auch wenn mir eine Statuswebseite angezeigt wird. Ich überlege derzeit, ob sich die Anschaffung einer VIPA Micro mit Analog Out Modul lohnt. Des basteln wegen sicher, aber um die 400€ ist auch nicht grad einfach.
Ein Kommunkationsmodul mit Speed-Bus für die 313 liegt von Siemens in der Bucht zwischen 1€ und 850€, bei VIPA das große bei ~1300. Ich denke, da ist klar, das ich dann eher das HMI erstmal als GW mißbrauche.

Trotzdem danke für das Modul, es kommt der Tag, an dem ich es einsetzen werde :)