# TCP bzw. Modbus Verbindung sicher Schließen bei CPU Stopp



## Hesse (20 April 2022)

Wenn die CPU in Stopp geht bzw. dorthin geschaltet wird, bleiben bestehende Verbindungen wohl offen und werden nicht beendet.

Wie ist es zu lösen das Verbindungen *erst* sicher geschlossen werden?

Gibt es ein CPU Shutdown oder das Gegenteil zu Startup


----------



## DeltaMikeAir (20 April 2022)

Hesse schrieb:


> Wenn die CPU in Stopp geht bzw. dorthin geschaltet wird


Mal die erste Frage, warum geht die CPU in Stopp bzw. warum wird sie manuell in Stopp geschaltet?

Um was für eine CPU geht es und um was für eine Verbindungsart?


----------



## Hesse (20 April 2022)

Sorry :

CPU S7-1200 FW 4.3

TIA V15.1

Zum Beispiel wenn Tia das beim Laden will

oder mann beim Teste über Tia in Stopp schaltet.

Da es in der Praxis vorkommen kann,über eine Eingang die 24 V abfragen und so Zeit gewinnen geht ja in dem Fall nicht.

Gerät: ein Wechselrichter der empfindlich auf nicht geschlossene Verbindungen reagiert,

und dann längere Zeit Sperrt (und der Hersteller wohl das als „Extra“ bezeichnet und nicht als Bug)


----------



## DeltaMikeAir (20 April 2022)

Hesse schrieb:


> Gerät: ein Wechselrichter der empfindlich auf nicht geschlossene Verbindungen reagiert,


D.h. es ist ein projektierter PN-Teilnehmer? Das der Umrichter bei Verbindungsunterbrechung auf Störung geht halte ich für normal. Wie sollte er auch sonst reagieren, wenn seine Steuerquelle nicht mehr verfügbar ist. Bei Verbindungsaufbau muss man ihn dann eben wieder quittieren.

PS:
Was bedeutet


> und dann längere Zeit Sperrt


----------



## PN/DP (20 April 2022)

Hesse schrieb:


> Gerät: ein Wechselrichter der empfindlich auf nicht geschlossene Verbindungen reagiert,
> 
> und dann längere Zeit Sperrt (und der Hersteller wohl das als „Extra“ bezeichnet und nicht als Bug)


Könnte es sein, daß die eigentliche Funktion eine Ansprechüberwachung wie bei einem Feldbus ist, und bei Ausbleiben der Kommunikation das Gerät gewollt/korrekt in einen (sicheren) Aus-Zustand geht? Dann hat das nichts mit nicht geschlossenen/beendeten Verbindungen zu tun und der Umrichter wird immer "empfindlich" auf den Ausfall der Kommunikation reagieren, und möglicherweise kannst Du da auch nichts dagegen unternehmen. Oder steht irgendwie im Handbuch des WR wie man den auf den Ausfall der Verbindung vorbereiten kann?

Was ist so schlimm an diesem Verhalten? Wie startest Du das System wieder auf nach der "empfindlichen" Reaktion? Z.B. jedes dezentrale I/O verhält sich so und das ist da ganz normales Systemverhalten.

(PS: zu lange getippselt, DMA war schneller)

Harald


----------



## Hesse (20 April 2022)

DeltaMikeAir schrieb:


> D.h. es ist ein projektierter PN-Teilnehmer?


Nein , nur über eine Verbindung mit MB_Client werden Daten alle 5 sec abgeholt.

Das funktioniert auch …


DeltaMikeAir schrieb:


> Was bedeutet


Er „sperrt“ die Kommunikation per Modbus, lässt kein neuer Verbindungsaufbau zu.

Auch von einer anderen IP dann nicht mehr. Erst nach Stunden ist ein neuer Verbindungsaufbau möglich.

manchmal hilft auch nur Netz Aus/Ein



DeltaMikeAir schrieb:


> Bei Verbindungsaufbau muss man ihn dann eben wieder quittieren.


Da ist nix mit Quittieren, „der hört einfach nicht mehr Zu“


PN/DP schrieb:


> Was ist so schlimm an diesem Verhalten? Wie startest Du das System wieder auf nach der "empfindlichen" Reaktion?


-Keller laufen
-Ac Sicherung Aus
-DC Trennschalter Aus
-(Batterie (wenn ich eine hätte) Aus)
-Warten …warten ... warten...
-DC Trennschalter Ein
-AC Sicherung Ein
-raus aus Keller

Da habe ich eine andere Auffassung von: „Quittieren“

Edit:
Wenn ich die Verbindung vor einem Stopp
„Ordnungsgemäß beende“ (Schalter an einem DI)
Zeigt er das empfindlich verhalten bisher nicht


----------



## DeltaMikeAir (20 April 2022)

Und was ist das genau für ein Umrichter?


----------



## Hesse (20 April 2022)

DeltaMikeAir schrieb:


> Und was ist das genau für ein Umrichter?


SUNGROW SH5.0RT   Hybrid-Wechselrichter

Danke für das rege Interesse....
Entnehme ich der vielen Gegenfragen die „Aussage“
„Ein Sicheres beenden vor stopp ist nicht möglich“?


----------



## DeltaMikeAir (20 April 2022)

Hesse schrieb:


> Entnehme ich der vielen Gegenfragen


Die vielen Gegenfragen sind nur notwendig, um sich mal einen Überblick zu verschaffen was da aufgebaut und vorhanden ist.
Ansonsten kann man ja kaum eine Aussage treffen.


Hesse schrieb:


> „Ein Sicheres beenden vor stopp ist nicht möglich“?


Da man den Stopp bei der S7-1500 nicht auswerten kann ( ala OB100 nur anders herum ), wird es auf deinem gewünschten Weg nicht möglich sein.
Ich könnte mir als Möglichkeit vorstellen, dass du die Verbindung vor dem übertragen des SPS-Programm gezielt abbaust und
erst nach dem Neustart der CPU wieder frei gibst.

Ich habe bei deinem Umrichtertyp gelesen, dass auch andere Endanwender Probleme damit haben und der DE-Support nur sagt "Gerät ausschalten, 10 Minuten warten => wieder einschalten ). Was natürlich eine schwache Leistung ist 

Hängt die CPU direkt an dem Umrichter per Ethernetkabel oder ist da noch ein Switch dazwischen?


----------



## PN/DP (20 April 2022)

Hesse schrieb:


> Da habe ich eine andere Auffassung von: „Quittieren“
> 
> Edit:
> Wenn ich die Verbindung vor einem Stopp
> ...


Ich vermute mal, der Kommunikationsausfall wird im Umrichter über einen (einstellbaren?) Timeout erkannt und reagiert. Da hast Du gute Chancen, den DI des Umrichters bei CPU-STOP vor dem empfindlichen Verhalten abzuschalten. Also an einen SPS-DQ ein Koppelrelais anschließen, die Relaiskontakte an den DI des Umrichters. Den SPS-DQ im SPS-Programm (immer) einschalten. Bei SPS-STOP oder Ausfall Betriebsspannung wird dann das Relais abfallen.

Führt das "ordnungsgemäße Beenden" am DI zum Abschalten des Umrichters oder wird da nur der Kommunikationsausfall ignoriert und der Umrichter läuft dann unkontrolliert weiter?

PS: Meinst Du einen DI am Umrichter oder einen DI an der SPS? Falls SPS: was macht die SPS wenn der DI abgeschaltet wird?

Harald


----------



## DeltaMikeAir (20 April 2022)

@Hesse,

wäre es eine Lösung für dich, den Timeout-Wert höher zu setzen. Da du ja nur Daten ausliest, hätte es ja keine Auswirkungen auf einen Prozess:



Quelle: Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden


----------



## PN/DP (20 April 2022)

DeltaMikeAir schrieb:


> Quelle: Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden


OMG, was für eine Bastelei mit halbfertigen Geräten mit buggy Software, von Leuten die nicht wirklich wissen was sie tun...  (wo ist der Smiley wo die Haare zu Berge stehen???)

Also ich kann nicht finden daß der Umrichter eine zyklische Kommunikation braucht. Für mich sieht das "empfindliche Verhalten" wie ein Bug in der Implementation der Modbus state machine in der Software des Umrichters aus. ---> Frage den Support des Umrichter-Herstellers

Und nochmal meine Frage:


PN/DP schrieb:


> PS: Meinst Du einen DI am Umrichter oder einen DI an der SPS? Falls SPS: was macht die SPS wenn der DI abgeschaltet wird?



Harald


----------



## Blockmove (20 April 2022)

PN/DP schrieb:


> OMG, was für eine Bastelei mit halbfertigen Geräten mit buggy Software, von Leuten die nicht wirklich wissen was sie tun...  (wo ist der Smiley wo die Haare zu Berge stehen???)


Tja Harald, das ist die schöne neue Smarthome-Welt  🤣

Alles lässt sich problemlos vernetzten.
Modbus, MQTT, JSON sind ja alles Standard-Protokolle und einfach handlebar.
Wenn der Hersteller in China sitzt ... kein Thema 

So wie's aussieht ist halt bei dem Solar-Wechselrichter die Statemachine für die Modbus-Kommunikation schlampig umgesetzt und irgendwo ein Timeout vergessen worden. Passiert schon mal.

@Hesse 
Ich hab keinen Sungrow PV-Wechselrichter, aber mein Senec Batteriespeicher ist auch zickig.
Meine Lösung ist, dass ich ioBroker auf einem Raspi als Gateway verwende.
Macht weniger Ärger als die direkte Kommunikation über SPS.


----------



## Hesse (20 April 2022)

Ich wollte vermeiden das dies das mindestens Dritte Forum ist was sich mit dem Modbus Problem von Sungrow auseinander setzt und der Support es nicht zugibt ….

Ja, Ich such ein Workaround

Die genagten Foren kenn ich alle :-(

Dann muss ich wohl:

alle 5s Verbindung aufbauen
Daten holen
Verbindung abbauen
Nach 5s das gleich e wieder …



PN/DP schrieb:


> PS: Meinst Du einen DI am Umrichter oder einen DI an der SPS? Falls SPS: was macht die SPS wenn der DI abgeschaltet wird?


an der SPS
ich schalte Disconeckt vom MB_Client auf "1"



DeltaMikeAir schrieb:


> wäre es eine Lösung für dich, den Timeout-Wert höher zu setzen.


ich lese mit der SPS nicht mit iobrocker ! die Einstellungen sind vom iobrocker



PN/DP schrieb:


> Frage den Support des Umrichter-Herstellers



Danke ....

INFO:
Bei mir steigt nur die Modbus Kommunikation aus, nicht der Ganze Umrichter.
Der macht (zumindest bei mir) weiter seinen Dienst .Nur hört er nicht mehr auf Modbus anfragen
Er „hört“ dann weder auf SPS noch auf PC-MB-Client Programme


----------



## DeltaMikeAir (20 April 2022)

Hesse schrieb:


> alle 5s Verbindung aufbauen
> Daten holen
> Verbindung abbauen
> Nach 5s das gleich e wieder …


Und hoffen dass nicht genau zwischen Aufbauen und Abbauen die SPS auf Stopp geht.



Hesse schrieb:


> Ich wollte vermeiden das dies das mindestens Dritte Forum ist was sich mit dem Modbus Problem von Sungrow auseinander setzt und der Support es nicht zugibt ….


Da hätte ich jetzt keine Schmerzen mit


----------



## Blockmove (20 April 2022)

Hesse schrieb:


> Dann muss ich wohl:
> 
> alle 5s Verbindung aufbauen
> Daten holen
> ...



DAS ist eigentlich Standard bei nicht zyklischer Abfrage.
Solltest du generell bei der Datenabfrage über Modbus so handhaben.


----------



## Hesse (20 April 2022)

Blockmove schrieb:


> DAS ist eigentlich Standard bei nicht zyklischer Abfrage.
> Solltest du generell bei der Datenabfrage über Modbus so handhaben.


Wo hört Zyklisch auf und fängt nicht Zyklisch an ?

Bei einem SPS Zyklus ?
Bei 100ms , 1 s , 5s , Minute ?


----------



## Blockmove (20 April 2022)

Hesse schrieb:


> Wo hört Zyklisch auf und fängt nicht Zyklisch an ?
> 
> Bei einem SPS Zyklus ?
> Bei 100ms , 1 s , 5s , Minute ?


Zyklisch bezieht sich auf den SPS-Zyklus bzw. auf die Laufzeit der Bausteine.

Generell:
Bei den meisten Netzwerkprotokollen ist es sinnvoll Verbindungen nicht offen zulassen.
Ganz besonders wenn einfache Mikrocontroller im Einsatz sind. 
Ich hab da auch schon kräftig geflucht.
Modbus ist oft extrem schlampig umgesetzt.


----------



## JoGi65 (20 April 2022)

Meines Erachten ist da die Simatic nicht ganz unschuldig. Passiert beim Fronius und bei meiner Ladestation auch, wenn man an der SPS arbeitet und Dinge verändert und läd etc.

Normalerweise läuft das ganze an, wenn man bei dem, von der TCON_IP_v4 erstellten Baustein unter Programmressourcen, "Startwerte als aktual Werte laden" durchführt.
Ansonsten den Fehler vom Modbiusbaustein anschauen. Ich verwende noch den Abbau der Tcon wenn dieser fehler auftritt.


```
// Fehlerbehandlung Modbus Fehler 80A3 - Abbau TCON
REGION Fehlerbehandlung
    IF "DB_Modbus_Ladestation".Status = 16#80A3 THEN
        "DB_Modbus_Ladestation".Fehler_Disconnect.Fehler := TRUE;
        "DB_Ladestation_Charger".Schritt := 1;
    ELSE
        "DB_Modbus_Ladestation".Fehler_Disconnect.Fehler := FALSE;
    END_IF;
    
    "TDISCON_DB_Modbus_Ladestation"(REQ := "DB_Modbus_Ladestation".Fehler_Disconnect.Fehler,
                                    ID := 4,
                                    DONE => "DB_Modbus_Ladestation".Fehler_Disconnect.Done);
END_REGION
```

Das setzt die Verbindung im Fehlerfall zurück. ID mußt halt schauen.


----------



## PN/DP (20 April 2022)

JoGi65 schrieb:


> Meines Erachten ist da die Simatic nicht ganz unschuldig.


Es kann immer mal passieren, daß eine TCP-Verbindung unerwartet unterbrochen wird. Das müssen die Kommunikationsteilnehmer abkönnen.
Die Simatic erholt sich ja wieder bzw. kann resettet werden.
Der Sungrow Umrichter hier erholt sich aber nicht wieder und es kann auch kein anderer Modbus Client eine Verbindung aufbauen. Da kann die Simatic nicht dafür.

@Hesse
Anstatt den Umrichter komplett auszuschalten reicht es vielleicht auch, das Netzwerkkabel für 2 Minuten abzuziehen? Vielleicht merkt der Umrichter dann, daß keine Verbindung mehr besteht und resettet die Modbus Kommunikation?

Harald


----------



## Blockmove (20 April 2022)

PN/DP schrieb:


> Es kann immer mal passieren, daß eine TCP-Verbindung unerwartet unterbrochen wird. Das müssen die Kommunikationsteilnehmer abkönnen.
> Die Simatic erholt sich ja wieder bzw. kann resettet werden.
> Der Sungrow Umrichter hier erholt sich aber nicht wieder und es kann auch kein anderer Modbus Client eine Verbindung aufbauen. Da kann die Simatic nicht dafür.



Harald du darfst da keine Industriemaßstäbe anlagen.
AEG (Ausschalten - Einschalten - Gut) ist in dem Bereich völlig normal.
Den Entwickler / Hersteller interessieren doch die paar Smarthome-Bastler die die Modbus-Schnittstelle nutzen einen Dreck.
Bananenware (Reift beim Kunden) ist da Standard.
Manche Hersteller machen das sogar richtig clever und nutzen Foren und / oder Social Media und bauen eine Communitiy rund um ihr Produkt auf.
Loxone ist jahrelang auf der Schiene geritten.


----------



## Hesse (20 April 2022)

PN/DP schrieb:


> @Hesse
> Anstatt den Umrichter komplett auszuschalten reicht es vielleicht auch, das Netzwerkkabel für 2 Minuten abzuziehen? Vielleicht merkt der Umrichter dann, daß keine Verbindung mehr besteht und resettet die Modbus Kommunikation?


Das, klappt manchmal auch aber nicht immer.

Im gesamten war heute alles schon mal besser als die vergangen Tage.
Es ist irgendwie wie mit den Frauen:
Wenn du weist was sie hören wollen und du dich *genau* so verhältst ist alles gut.
Machst du etwas Falsches … gehst du besser gleich in den Keller.


----------



## Matze001 (21 April 2022)

Ein kleiner Hack für zwischendrin... 

Falls Du eine Visu hast, mach Dir doch einen Button um die Kommunikation zu beenden / unterbinden.
Bevor Du also bewusst Änderungen auf Deine Steuerung überträgst, deaktiviere vorher die Kommunikation.

Die Fehlerfälle wie z.B. Stromausfall müssen dann immer noch betrachtet und behandelt werden, aber hier ist auch die Auftrittwarscheinlichkeit geringer.

Grüße

Marcel


----------



## PN/DP (21 April 2022)

Matze001 schrieb:


> Falls Du eine Visu hast, mach Dir doch einen Button um die Kommunikation zu beenden / unterbinden.
> Bevor Du also bewusst Änderungen auf Deine Steuerung überträgst, deaktiviere vorher die Kommunikation.


Oder einfach per Beobachtungstabelle eine (nicht-remanente) Variable steuern: 0=enable/1=disconnect MB-Kommunikation

Harald


----------



## Hesse (24 April 2022)

PN/DP schrieb:


> Oder einfach per Beobachtungstabelle eine (nicht-remanente) Variable steuern: 0=enable/1=disconnect MB-Kommunikation


so mache ich das auch 

aber :

Ich habe immer noch Probleme wenn ich die Verbindung beende, dann blockiert mein WE
Lass ich alles schön durchgehend laufen, funktioniert alles Stundenlang.
Die Daten kommen alle 5 Sekunden


Blockmove schrieb:


> Bei den meisten Netzwerkprotokollen ist es sinnvoll Verbindungen nicht offen zulassen.




Wie ist das richtige vorgehen das umzusetzen?

MB_CLIENT "(REQ := 0
Und
DISCONNECT auf 1

Ist das so korrekt ?

und sind Timings einzuhalten


----------



## PN/DP (24 April 2022)

Hesse schrieb:


> Wenn ich die Verbindung vor einem Stopp
> „Ordnungsgemäß beende“ (Schalter an einem DI)
> Zeigt er das empfindlich verhalten bisher nicht





Hesse schrieb:


> ich schalte Disconeckt vom MB_Client auf "1"
> (...)
> Bei mir steigt nur die Modbus Kommunikation aus, nicht der Ganze Umrichter.
> Der macht (zumindest bei mir) weiter seinen Dienst .Nur hört er nicht mehr auf Modbus anfragen





Hesse schrieb:


> Ich habe immer noch Probleme wenn ich die Verbindung beende, dann blockiert mein WE


Ist das jetzt ein neues Problem? Was heißt "_blockiert_"?

Harald


----------



## Blockmove (24 April 2022)

Hesse schrieb:


> Wie ist das richtige vorgehen das umzusetzen?
> 
> MB_CLIENT "(REQ := 0
> Und
> ...



Zeig mal deinen Baustein


----------



## Hesse (24 April 2022)

PN/DP schrieb:


> Ist das jetzt ein neues Problem? Was heißt "_blockiert_"?


Das Neue Problem ist das alte...

Auch bei schalten von DISCONNECT auf 1
Ist anschließen keine Kommunikation mit dem WE mehr per Modbus möglich

Arbeiten tut der WE weiterhin nur hört er nicht mehr aus MB Anfragen
Auch nicht aus Anfragen von einem PC-Programme
Erst wieder nach Netzkabel ziehen und stecken oder Netz aus Ein


----------



## 312C (24 April 2022)

Interessant wäre es mal das Verhalten des Wechselrichters bei Kommunikation mit einem anderen Client zu beobachten, wie zum Beispiel mit einem PC oder mit einer anderen SPS. Eventuell verträgt die miese Implementierung des Protokolls im WR nicht, dass die S7 mit den OUC Bausteinen eine TCP Verbindung (außer S7-1500 in V17) niemals vernünftig abbauen kann, sondern immer nur einen TCP-Reset schickt.


----------



## Hesse (24 April 2022)

Blockmove schrieb:


> Zeig mal deinen Baustein


Mir geht es nur darum:
Ist der Zeitlich Ablauf korrekt zum Trennen der Verbindung

Erst
DISCONNECT auf 1
Und
Dann
MB_CLIENT "(REQ := 0

Der Baustein ist nicht von mir alleine daher kann ich ihn nicht einfach posten.

Ich schreib aber einen „Neutralen mit demselben Problem“


----------



## Hesse (24 April 2022)

312C schrieb:


> wie zum Beispiel mit einem PC


Mit ein PC Client (z.b Modbus Poll) zeigt er das Verhalten nicht

Mein Sohn versucht sich gerade an ioBroker, ich berichte


----------



## 312C (24 April 2022)

Hesse schrieb:


> Mit ein PC Client (z.b Modbus Poll) zeigt er das Verhalten nicht
> 
> Mein Sohn versucht sich gerade an ioBroker, ich berichte


Was passiert wenn du mit der PC-Software verbunden bist und dann plötzlich die Netzwerkverbindung trennst ? (z.B. WiFi ausschalten oder Netzwerkkabel ziehen) Tritt das Problem dann auch auf ? Dann könnte dieser Unterschied (PC-Software, die Verbindung korrekt mit TCP Finish abbaut gegenüber S7, die einfach ein Reset schickt) tatsächlich das sein, was die Implementierung im Wechselrichter nicht verträgt. Dann könntest du aber tatsächlich nichts dagegen tun, denn bei der 1500er gibt es mittlerweile den TCONSettings- Baustein, mit dem man das Verhalten beim Schließen der Verbindungen einstellen kann, bei der 1200er aber noch nicht...


----------



## Blockmove (24 April 2022)

312C schrieb:


> Was passiert wenn du mit der PC-Software verbunden bist und dann plötzlich die Netzwerkverbindung trennst ? (z.B. WiFi ausschalten oder Netzwerkkabel ziehen) Tritt das Problem dann auch auf ? Dann könnte dieser Unterschied (PC-Software, die Verbindung korrekt mit TCP Finish abbaut gegenüber S7, die einfach ein Reset schickt) tatsächlich das sein, was die Implementierung im Wechselrichter nicht verträgt. Dann könntest du aber tatsächlich nichts dagegen tun, denn bei der 1500er gibt es mittlerweile den TCONSettings- Baustein, mit dem man das Verhalten beim Schließen der Verbindungen einstellen kann, bei der 1200er aber noch nicht...


Vielleicht mal der Sache mit Wireshark auf den Zahn fühlen.
Es gibt einen Wireshark Modbus-Filter
https://sbc-support.com/de/faq/101441/


----------



## Hesse (24 April 2022)

312C schrieb:


> Was passiert wenn du mit der PC-Software verbunden bist und dann plötzlich die Netzwerkverbindung trennst ? (z.B. WiFi ausschalten oder Netzwerkkabel ziehen) Tritt das Problem dann auch auf ?


Nein dann passiert es nicht …..
Netzwerkkabel ziehen hat zur Folge:

Timeout Fehler am PC Programm
Nach stecken vom Netzwerkkabel dauert es ein Moment und er fängt sich wider
Datenabfrage geht weiter, ohne zutun meinerseits.


----------



## 312C (24 April 2022)

Hesse schrieb:


> Nein dann passiert es nicht …..
> Netzwerkkabel ziehen hat zur Folge:
> 
> Timeout Fehler am PC Programm
> ...


Hm. Da kann man jetzt nur spekulieren ohne das PC-Programm auch genau zu kennen. Dann würde ich als nächstes tatsächlich mal Wireshark anwerfen.


----------



## Blockmove (24 April 2022)

Hesse schrieb:


> Nein dann passiert es nicht …..
> Netzwerkkabel ziehen hat zur Folge:
> 
> Timeout Fehler am PC Programm
> ...


Da du das SPS-Programm nicht zeigst, bleibt dir wohl nur die Analyse mit Wireshark.


----------



## Hesse (24 April 2022)

312C schrieb:


> Hm. Da kann man jetzt nur spekulieren ohne das PC-Programm auch genau zu kennen. Dann würde ich als nächstes tatsächlich mal Wireshark anwerfen.


Ok. Ich arbeite dran …… kann aber erst wieder testen wenn mein Sohn nicht mehr mit ioBroker fragt


----------



## Hesse (24 April 2022)

Blockmove schrieb:


> Da du das SPS-Programm nicht zeigst,


Dem komme ich noch nach ….


----------



## Hesse (25 April 2022)

Guten Morgen,
ich habe nochmal was “neu“ zusammen geklickt diesmal Komplet in FUP nicht in SCL.

Mit dem "Neuen Programm"  zeigt der Wechselrichter (WR) genau das gleich Verhalten.

- Daten kommen normal an

- 1x SPS Stopp /Start oder Schalter Disconnect

- WR „hört“ nicht mehr.


----------



## Thomas_v2.1 (25 April 2022)

Es lässt sich im übrigen nicht sagen, dass das Verhalten des Geräts grundsätzlich falsch ist. Wenn auf Anwendungsebene keine Keepalives ausgetauscht werden, dann schlägt hier spätestens der TCP Keepalive an. Und diese Keepalive-Telegramme werden unter Linux wie unter Windows in Voreinstellung nach 2 Stunden gesendet. Wenn hier jemand einen Modbus-TCP Server startet, dieser grundsätzlich nur eine einzige Verbindung zulässt, dann kann es unglücklicherweise eben sein, dass eine Verbindung bis zu 2 Stunden hängen bleibt. Da gibt es noch viel mehr Fälle bei denen das vorkommen kann, als nur wenn die SPS in Stopp geht und die Verbindung nicht getrennt wird.

Bei Siemens CPs der 300/400er Serie lässt sich darum das Keepalive-Intervall selber einstellen, und Voreinstellung sind hier 30 Sekunden. Und beispielswiese auf dem S7 Protokoll schicken Siemens PGs Iso-On-TCP Telegramme ohne weitere Nutzdaten um den Verbindungszustand zu überprüfen. Im Grunde bleibt nur zu prüfen ob bei deinem Modbus-TCP Server das Keepalive herabgesetzt werden kann, oder die möglichen Verbindungen heraufgesetzt werden können.


----------



## Hesse (26 April 2022)

Thomas_v2.1 schrieb:


> Im Grunde bleibt nur zu prüfen ob bei deinem Modbus-TCP Server das Keepalive herabgesetzt werden kann, oder die möglichen Verbindungen heraufgesetzt werden können.


Dazu habe ich keine Einstellungsmöglichkeit gefunden.
Auch scheint der WR nur eine Verbindung zuzulassen.

Mein Sohn hat zwischenzeitlich iOBroker zum Laufen bekommen.
Wenn ich jetzt die Sps Anschalte und die Abfrage gestartet wird, kommen im iOBroker
keine Daten mehr an.


Blockmove schrieb:


> Meine Lösung ist, dass ich ioBroker auf einem Raspi als Gateway verwende.
> Macht weniger Ärger als die direkte Kommunikation über SPS.


Das werde ich dann wohl auch so machen müssen.
Welchen Weg gehst du da? Welchen Bus ?
Hast du Googlefutter oder einen Link wie die Daten in iOBroker bereit zu stellen sind,
das die SPS sie holen kann.


----------



## PN/DP (26 April 2022)

Thomas_v2.1 schrieb:


> Es lässt sich im übrigen nicht sagen, dass das Verhalten des Geräts grundsätzlich falsch ist. Wenn auf Anwendungsebene keine Keepalives ausgetauscht werden, dann schlägt hier spätestens der TCP Keepalive an. Und diese Keepalive-Telegramme werden unter Linux wie unter Windows in Voreinstellung nach 2 Stunden gesendet. Wenn hier jemand einen Modbus-TCP Server startet, dieser grundsätzlich nur eine einzige Verbindung zulässt, dann kann es unglücklicherweise eben sein, dass eine Verbindung bis zu 2 Stunden hängen bleibt.


Ich denke, bei ModbusTCP ist ein Keep Alive Mechanismus gar nicht nötig. Ich habe sowas im Zusammenhang mit Modbus auch noch nicht gehört. Serverseitig reicht eigentlich die Implementation eines Session-Idle-Timeout, oder es kann auch gar nichts implementiert werden. Bei ModbusTCP wird empfohlen, die älteste unbenutzte Verbindung zu schließen und die neue Verbindung zu akzeptieren.

https://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
Kapitel 4.2 TCP CONNECTION MANAGEMENT


> a mechanism must be implemented in case of exceeding the number of authorized connection. In such a case we recommend to close the oldest unused connection.


Das macht der Modbus Server hier im WR aber offensichtlich nicht. Anscheinend beherrscht er auch kein Media Sense bzw. reagiert nicht drauf?




Hesse schrieb:


> Dann muss ich wohl:
> 
> alle 5s Verbindung aufbauen
> Daten holen
> ...


Empfehlung für ModbusTCP Clients:


> It is recommended to keep the TCP connection opened with a remote device and not to open and close it for each MODBUS/TCP transaction



Harald


----------



## Thomas_v2.1 (26 April 2022)

PN/DP schrieb:


> Ich denke, bei ModbusTCP ist ein Keep Alive Mechanismus gar nicht nötig. Ich habe sowas im Zusammenhang mit Modbus auch noch nicht gehört. Serverseitig reicht eigentlich die Implementation eines Session-Idle-Timeout, oder es kann auch gar nichts implementiert werden. Bei ModbusTCP wird empfohlen, die älteste unbenutzte Verbindung zu schließen und die neue Verbindung zu akzeptieren.
> 
> https://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
> Kapitel 4.2 TCP CONNECTION MANAGEMENT
> ...


Steht doch genau so unter 4.2.2, dass dafür der TCP Keepalive zuständig ist um die dort "half open" genannten Verbindungen als nicht mehr funktionstüchtig zu erkennen. Wenn ein Switch zwischen den Partnern hängt, und du schaltest nur die SPS ab, denn bleibt beim Server der Link auch bestehen. Darum glaube ich hier auch nicht, dass es das Problem grundsätzlich löst von der SPS auf irgendeinen anderen Client zu wechseln. Wenn der Server nur eine einzige Verbindung annimmt, dann gibt es auch kein Pool um ältere Verbindungen zu kappen (was ich generell unglücklich finde). Ich meine z.B. diese Janitza Geräte nehmen auch nur 2 oder 3 Modbus-TCP Clients an, ich hatte zumindest mal Geräte da war das genau so wackelig wenn man viel getestet hat. Kann natürlich bei diesem Gerät auch sein, dass dort ein eigener TCP Stack eingesetzt wird der keine TCP Keepalives kennt, denn die sind auch nicht zwingend vorgeschrieben. Sonst müsste das Gerät die Verbindungen spätestens nach üblich 2 Stunden als nicht mehr funktionierend erkennen und diese eine Serververbindung wieder freigeben.


----------



## PN/DP (26 April 2022)

Thomas_v2.1 schrieb:


> Wenn der Server nur eine einzige Verbindung annimmt, dann gibt es auch kein Pool um ältere Verbindungen zu kappen


Der "Pool" besteht dann aus nur 1 Verbindung, und der Server könnte generell bei Verbindungsversuchen die evtl. bestehende Verbindung kappen.
Das halte ich für wesentlich besser für den/die Clients als "ewig lange" Timeouts.

Kann man eigentlich bei dem TIA MB_CLIENT den eigenen (ausgehenden) Port festlegen? Vielleicht anerkennt der Server dann eingehende Pakete vom auch vorher verwendeten Port für die bereits bestehende "halb offene" Verbindung? Oder kommt der MB_CLIENT dann nicht über den versuchten neuen Verbindungsaufbau hinaus? Oder könnte der MB_CLIENT dann einen "ordnungsgemäßen" Verbindungsabbau noch nachschieben?

Harald


----------



## Hesse (26 April 2022)

PN/DP schrieb:


> Kann man eigentlich bei dem TIA MB_CLIENT den eigenen (ausgehenden) Port festlegen?


----------

