Siemens S7 Verbindungsstatus

Deine Einstellungen sind falsch. Kann gerade nicht nachschauen, aber die Werte sind 0 , 2 und 1, 0 oder auch umgekehrt., weiß ich im Momemt nicht genau.

mfg
cäsar

Hi,

meinst du für

CPU Rack: 0
CPU Slot: 2
MPI-Local: 1
MPI-Remote: 0 (1)

Was hat denn MPI mit einer TCP Connection zu tun?

EDIT: ----------------------------------------------------------------------------------

Habs mit

CPU Rack: 0
CPU Slot: 2
MPI-Local: 1
MPI-Remote: 0

CPU Rack: 0
CPU Slot: 2
MPI-Local: 0
MPI-Remote: 1

probiert. Ohne Erfolg

Hallo,
hab gerade nochmals getestet und dabei 200 Instanzen benutzt (150 REAL, 32 BOOL, 18 INT benutzen alle eine DB als Quelle) und bekommen den Fehler von Dir einfach nicht nachgestellt

Habe dazu Pollingintervale von 6000 - 20000ms bzw. eben Auslesen über Script probiert und funktioniert immer

Das einzige ist wenn ich die Verbindung während des Auslesen abdrehe hagelt es manchmal eben unzählige Meldungen „Timeout when waiting for PLC response“ ==> aber das finde ich ja normal !!

Zum Thema Einstellungen denke ich kann auch bei Typ „ISO over TCP“ nicht viel falsch sein, den entweder steht die Verbindung oder nicht !!

Nochmals die Frage,

  1. Welches OS benutzt Du
  2. Welches Datum/Grösse hat die LIBNODAVE.DLL

tgusi74

Oh sorry, aber ich bin die ganze Zeit von einer Logo als Siemens-Instanz ausgegangen. Hab ich leider nicht genau gelesen.

mfg
cäsar

Hi,

  1. Welches OS: Windows8.1
  2. Welches Datum/Grösse hat die LIBNODAVE.DLL: 14.09.2012/124KB

Daten werden bei mir ebenfalls über Datenbausteine ausgetauscht.
Pollintervall Befehle (bool): 0ms
Pollintervall Meldungen (bool): 100ms
Pollintervall Werte (real): 60000ms

Servus,
bei mir hat die LIBNODAVE.DLL aber 126976 bytes !! —> Ich hänge diese mal hier an

Kannst Du mal die 100ms erhöhen auf mindestens 2000ms, denn ich denke es mach für IPS nur wenig Sinn die Daten in dieser Zykluszeit hochzuladen ==> persönlich bin ich sogar der Meinung das ein Auslesend er Daten über Script sinnvoller währe, pollen und auch verarbeiten und dann wieder den Script triggern (denke mal das man da so maximal an die 400ms Grenze kommt)

Windows 81. habe ich leider nicht hier zum testen !!

tgusi74

libnodave.zip (52.5 KB)

Hi,

In der Übersicht hat sie 124KB. Unter Eigenschaften steht dann eh auch 124 KB (126*976 Bytes).
Habe mit folgendem Skript sämtliche Pollzeiten auf 2000 geändert:

<?
$s7 = IPS_GetInstanceListByModuleID("{932076B1-B18E-4AB6-AB6D-275ED30B62DB}");   #  Alle S7-Instanzen holen

foreach ($s7 as $ids)   {
    IPS_SetProperty($ids,'Poller',2000);
	IPS_ApplyChanges($ids);
}
?>

Der Fehler scheint dadurch behoben zu sein. Bei Pollzeiten von 1000ms tritt der Fehler wieder auf.

Sind die Pollzeiten so hoch (2000ms), muss ich im worst case 2 Sekunden warten, bis die wahre Rückmeldung eintrifft. Das kann für die Bedienung echt nervig sein.
Das Pollen per Skript wäre ein Lösungsansatz (Workaround), nutzt dadurch aber nicht die Protokolleigenschaft einer S7-Verbindung (Polling).

Hallo,
habe jetzt auch nochmals etwas gespielt … und siehe da heute schaffe ich auch auf einmal eine Access Viloation

20:08:25.623 | FunctionName: S7_RequestRead, ThreadID: 9756, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 02B900C0
20:08:26.260 | FunctionName: S7_RequestRead, ThreadID: 9756, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 02B900C0
20:08:26.920 | FunctionName: S7_RequestRead, ThreadID: 9756, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 02B900C0
20:08:28.629 | FunctionName: S7_RequestRead, ThreadID: 9756, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 02B900C0
20:08:32.793 | FunctionName: S7_RequestRead, ThreadID: 9756, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 02B900C0
20:10:00.167 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03B900C3
20:10:00.615 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03B900C3
20:10:02.631 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03000008
20:10:07.788 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03B900C4
20:10:08.258 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03000008
20:10:08.294 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03B900C4
20:10:08.909 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03B900C4
20:10:09.619 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03B900C4
20:10:10.385 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03B900C4
20:10:10.672 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03B900C4
20:10:10.906 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03000008
20:10:12.142 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03000008
20:10:12.429 | FunctionName: S7_RequestRead, ThreadID: 9244, CrashReport: Access violation at address 007B32DE in module 'ips.exe'. Read of address 03B900C4

… bei mir ist vorhin die AUTODEFARGEMTIERUNG gelaufen, somit war der Rechner sehr eingebremst, hatte das auch Scriptlaufzeiten von ca. 12-15 Sekunden was jetzt wieder in 5 Sekunden passiert (die S7-Instanzen haben zu ca. 80% eine Variablenänderung zur Folge, sprich die Variable wird in IPS auch geändert)

@PARESY,
kannst Du verifizieren ob diese AccessViolation in IPS auftritt oder letzendlich in der Libary LIBNODAVE.DLL
(hast Du dir schon mal das MULTIPLIED READ der LibNoDave angeschaut, das konnte hier noch Performance bringen ==> währe das wohl ein Featurerequest :loveips: )

@SUNNI2002,
Du schreibst doch mit Sicherheit die Daten per Script zur PLC, da könntest Du doch für deine kritschen Rückmeldevariablen dann eine „S7_RequestRead“ nach ca. 50ms auslösen, somit hast Du eine sofortige Reaktion auf IPS-Seite !!

tgusi74

Hi tgusi74,

Gesagt, getan … Coole Idee! Funktioniert Klasse :slight_smile: So bin ich jetzt wenigstens von den Pollzeiten unabhängig …

… blöd is halt nur wenn ein Datenpunkt von der Automatik in der Steuerung gesetzt wird. Dann kommt nämlich wieder das Polling zum Tragen :rolleyes:

Hab heut wieder ein bissl getestet. Mit diesem Skript überprüfe ich alle 15 Sekunden ob die Verbindung noch steht:

<?

//***************************************************************************
//Verbindungsüberwachung und Neuaufbau bei Verbindungsabbruch
//09.12.2013 Guther

//nicht verwendetes Testbit wird in die Steuerung geschrieben, sollte dies
//nicht funktionieren, liefert die Funktion eine "0" zurück. Ist die Steuerung
//danach wieder erreichbar (Port offen) wird die Verbindung neu initialisiert
//***************************************************************************
IPSUtils_Include ("IPSLogger.inc.php", "IPSLibrary::app::core::IPSLogger");

# -------------------- KONFIG -------------------------------------
$s7_inst = 36766 /*[Siemens PLC]*/;
# -------------------- KONFIG -------------------------------------

$check   = S7_WriteBit(36615 /*[S7\Connection\ConnChecker]*/,true);
echo $check;
if ($check == 1) {
	SetValueBoolean(57019 /*[S7\Connection]*/, true);
}
else {
	SetValueBoolean(57019 /*[S7\Connection]*/, false);
}



//Falls Schreiben des Testbits nicht erfolgreich, Verbindung neu initialisieren
if ($check == 0)	{
	S7_SetOpen($s7_inst, false);
	IPS_ApplyChanges($s7_inst);
	IPS_Sleep(5000);
	S7_SetOpen($s7_inst, true);
	IPS_ApplyChanges($s7_inst);
	echo "Fehlerschleife wurde durchlaufen";
	IPSLogger_Inf('S7 CONN',"Connection NOK");
}
else {
  	IPSLogger_Inf('S7 CONN',"Connection OK");
}



?>

  • Alle Datenpunkte auf Pollingintervall = 20000ms gesetzt.
  • Netzwerkkabel zur Steuerung abgesteckt
  • ca. 1 Minute lang abgesteckt gelassen … danach wieder angesteckt
  • Verbindung wird wieder aufgebaut. ALLES OK

Beim Versuch mit alle Datenpunkte auf 10000ms keine Chance. Der Altbekannte Fehler tritt wieder auf …

Hallo sunni2002,
das mit den Überwachungsscript kannst Du Dir eigentlich sparen, den IPS versucht ja sowieso jetzt nach maximal 60 Sekunden wieder zu verbinden bzw. kannst Du Dir jetzt die Verbindungsinstanz ins Eventmanagment einpflegen dann wird eben bei „Statusänderung“ das Script getriggert (Alerting, Reconnect, …)

Natürlich ist ein Pollinginterval mit 20 Sekunden lange (vorallem wenn man vor den Bildschirm ist und auf Reaktion wartet) aber für die klasische Haustechnik doch irrelavant ob ein Temperatur etwas später angezeigt wird bzw. ob ein Status umspringt wenn dieser automatisch passiert ist ==> wichtig ist doch nur wenn man über die Oberfläche eine Aktion setzt das man sofortige Reaktion/Feedback hat

Weiss natülich nicht welche Daten da hinter deinen S7-Instanzen liegen, aber Du könntest dich auch mit optimierter Datenübertragung beschäfftigen, als z.B. ein WORD hochladen und das in die Einzelbitsbits zerlegen, somit nur ein Lesezugriff für 32 Einzelstati

… hab mal einen DB mit mehr als 3500Bytes mit PHP per Socketverbindung (Code liegt auch irgendwo hier im Forum) ausgelesen und die Einzelbytes zu einen Pixelbild zusammengebaut in kleiner 8 Sekunden (hab das zuerst auch über die S7-Instanz mit DoubleWords gelesen und das hat dann ca. 250 Sekunden gedauert)

Aber vielleicht erhört uns PARESY und stellt in IPS das „MULTIPLIED READ“ der LibNoDave.dll zur Verfügung :loveips:

tgusi74

Hallo Erwin,
heißt das jetzt, daß die Logo sich nun ohne Probleme wieder verbindet?

Kannst du mir mal genau erläutern, was ich da machen muß, damit dies auch bei mir funktioniert!

mfg
caesar

Hallo Caesar

Ich habe die Netzwerkverbindung bei der Logo gezogen und gewartet bis die Timeoutmeldung kam. Danach Verbindung wieder eingesteckt und bis zum nächsten Reconnect durch IPS gewartet --> alles wieder verbunden und lauffähig.
Ich arbeite nur mit 2 Logo und wenigen Datenpunkten.

Erwin

Achso, ich dachte du hast das Problem gelöst.
Manchmal klappt’s ja auch mit der Verbindung. Aber halt nicht immer.

mfg

Hallo,
bin jetzt nicht ganz schlau aus dem Thread geworden.
Gibt’s jetzt eine Lösung für Logo hinsichtlich des Verbindungsproblem’s?

mfg
cäsar

  1. Was steht im Logfile wenn sich die !Logo nicht mehr verbinden lässt ??
  2. Wie löst Du das Problem derzeit (IPS neu starten oder ist auch an der Steuerung etwas notwendig)

tgusi4

Hallo tgusi74,
die Netzwerkverbindung physikalisch steht innerhalb von 2 Sekunden, wenn ich das Netzwerkkabel wieder einstecke.
Das Problem ist die Verbindung zu IPS: läßt sich nur durch Neustart von IPS lösen.

Ist ja ein alt bekanntes Problem und ich finde es auch wie meine Vorredner sehr schade, daß dieses Problem von IPS nur
sporadisch oder gar nicht angegangen wird.

mfg
cäsar

Hallo

Ich habe das Logo 8 Verhalten nochmals getestet:

1: Netzwerkverbindung an der Logo ziehen
2: Im IPS Meldungsfenster erscheint jede Sekunden die Meldung:
Timeout when waiting for PLC response
nach der vollen Minute hören diese Meldungen auf
3: Kurze Zeit später erscheint im IPS Meldungsfenster:
Neuverbindung […] fehlgeschlagen
4: Netzwerkverbindung wieder gesteckt
5: Nach einiger Zeit (max 1 Minute??) erscheint die Meldung:
Neuverbindung […] erfolgreich
6: Alles wieder im Grünen

Bevor das so funktioniert hat(!!), habe ich die Verbindung mit einem Script überwacht und wenn nötig IPS über die Aufgabesteuerung von Windows neu gestartet.

Erwin

Hallo,
was hast du aktuell für eine Version von IPS?

mfg

Problem scheint nun doch gelöst!

  1. Update auf V 3.40 #3754

   S7_SetOpen(19146 /*[Siemens Test PLC]*/, false);
   IPS_ApplyChanges(19146 /*[Siemens Test PLC]*/ );
   IPS_Sleep(2000);Pausenzeit von 500 auf 2000 erhöht
   S7_SetOpen(19146 /*[Siemens Test PLC]*/ , true);
   IPS_ApplyChanges(19146 /*[Siemens Test PLC]*/ );

3.Ich werd’s bei ca. 25 Logo’s mittlerweile weiterhin beobachten, wäre super, wenn das jetzt klappen würde!

mfg
cäsar