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

[Hesse]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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 …

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

Bei Verbindungsaufbau muss man ihn dann eben wieder quittieren.

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

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]

Und was ist das genau für ein Umrichter?

 

[Hesse]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

„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]

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

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]

@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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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:

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]

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]

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 …

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"

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

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

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]

Dann muss ich wohl:

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

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

 

[Hesse]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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