Siemens S7 Verbindungsstatus

tgusi74 · 8. Juni 2015 um 00:17

Hallo,
leider erkennten nur die Schreibbefehle „S7_Write*“ bzw. eben der Lesebefehl „S7_RequestRead“ das etwas mit der Verbindung zur S7 nicht in Ordnung ist !!

… obwohl eigentlich permamant „Hinweismeldungen“ im Logging auftauchen z…B.: „Timeout, waiting for PLC response“ ==> hat man keine Möglichkeit das über das Eventhandling abzufangen und somit auch keine Möglichkeit selbst darauf zu reagieren

Ich sehe daher nur die einizige Möglichkeit, das zyklische lesen der S7-Instanzen (POLLING) über eine Script „SELBST“ zu machen, denn dann hat man die Möglichkeit eben auf Fehler zu reagieren !!

Habe dazu mal eine Funktion gemacht die das auslesen und wenn nötig eine RECONNECT durchführt, d.h. eben an den S7-Instanzen das POOLING auf 0 stellen und in einen eigenen Script mit Hilfe eines zyklischen Ereignis das auslesen durchführen

==> ein weiterer Vorteil ist durch das „selbst Auslesen“ das man ein sauberes Prozessabbild der S7 auf IPS-Seite hat

<?
include_once ('./common_function.php');
include_once ('./s7_function.php');


//Muster auslesen von Einzelinstanzen mit RECCONECT
$ret = Read_S7_Instance(33566 , 1);
if ($ret >= 1)
   {
    echo "Es ist der Fehler " . $ret . "beim lesen der S7-Instanz aufgetreten";
   }


//Muster auslesen aller S7-Instanzen
//0 = Alle S7-Instanzen auf Scriptebene = IPS_GetObject($_IPS['SELF'])['ParentID']
//11 = Reconnect auf erste Instanz mit einen Versuch
$ret = Read_ALL_S7_Instance_of_Level(0,11);
if ($ret >= 1)
   {
    echo "Es ist mindestens ein Fehler beim lesen der S7-Instanzem aufgetreten (" . $ret .")";
   }

?>

P.S. Ich selbst benutze ja sowieso das ganze mit nur „einer S7-Addressinstanz“ und konfiguriere diese immer beim auslesen „ON THE FLY“ um und funktioniert schon seit Jahren quasi fehlerfrei (habe nie Probleme mit Reconnect)

@paresy,

Warum kann man die Hinweismeldungen nirgends im Eventhandling abfangen / mitbekommen
wenn an der Verbindungsinstanz „DeltaLogic Netlink Pro“ eingestellt ist, kann der DIENST nicht mehr beendet werden
im Build #3751, erscheinen bei Verbindungsinstanzen die nicht aktiv sind keine GRAUEN RUFZEICHEN mehr

Hänge mal hier alle meine S7-Scripts an, sollte es zu verständnissproblemen kommen einfach melden

tgusi74

S7_SCRIPTS.zip (242 KB)

paresy · 12. Juni 2015 um 09:26

@tgusi74: Magst du die #3755 mal testen? Sobald ein Fehler beim Lesen/Schreiben erkannt wird, wird die I/O Instanz als Fehlerhaft markiert, sodass der Automatische Reconnect greift und du auch per Event Control darauf reagieren kannst. Zusätzlich habe ich noch ein wenig an der Logik verändert, die evtl. das Reconnect robuster macht.

@all: Mich würde interessieren, ob mit dieser Version in eurem Log noch die AccessViolations auftreten, oder ihr etwaige „Connection crashed“ Meldungen finden könnt.

paresy

sunni2002 · 12. Juni 2015 um 19:14

Hi,

Folgenden Fehler bekomme ich nach dem Beenden/Starten der Instanz:

12.06.2015 19:08:04.100 |     0 | ERROR   | ScriptEngine         | FunctionName: IPS_ApplyChanges, ThreadID: 836, CrashReport: Access violation at address 007B1C0B in module 'ips.exe'. Write of address 00000000

Nach beenden und starten des IPS-Dienstes läuft die Instanz wieder …

LiveUpdate Version: 12.06.15, #3754

sunni2002 · 12. Juni 2015 um 19:30

LiveUpdate Version: 12.06.15, #3755

Bekomme noch folgenden Fehler:

12.06.2015 19:29:08.686 |     0 | ERROR   | ScriptEngine         | FunctionName: IPS_ApplyChanges, ThreadID: 5100, CrashReport: Access violation at address 007B2F67 in module 'ips.exe'. Write of address 00000000

tgusi74 · 14. Juni 2015 um 11:55

Hallo,
hab mal das System propoziert und der „automatische Reconnect“ hat immer wieder sauber verbunden

… auch der „Eventscript auf den überwachten Instanzen“ wurde immer informiert

S7_RECONNECT TEST
=================

13.06.2015 20:46:09.775 | 33698 | WARNING | TimerID #5, TimerThread #7 | [TEST\OFFENREGELUNG] = Timeout when waiting for PLC response
13.06.2015 20:46:09.775 | 36569 | DEBUG   | ExecuteThreadID #18  | Skriptausführung: IPS_EVENTCONTROL.PHP ~ Absender: StatusEvent
13.06.2015 20:46:09.806 |     0 | CUSTOM  | IPS_EVENTCONTROL     | An Instanz '11108-Siemens_S7' ist Statusevent '200 - Error' aufgetreten !!
13.06.2015 20:46:09.806 | 36569 | DEBUG   | ExecuteThreadID #18  | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 35 ms

13.06.2015 20:46:16.681 | 11108 | ERROR   | EventControl         | Neuverbinden [Siemens_S7] fehlgeschlagen = no message defined!

13.06.2015 21:01:19.525 | 11108 | ERROR   | EventControl         | Neuverbinden [Siemens_S7] fehlgeschlagen = no message defined!

13.06.2015 21:03:19.540 | 11108 | ERROR   | EventControl         | Neuverbinden [Siemens_S7] fehlgeschlagen = no message defined!

13.06.2015 21:04:19.634 | 11108 | MESSAGE | EventControl         | Neuverbinden [Siemens_S7] erfolgreich
13.06.2015 21:04:19.634 | 36569 | DEBUG   | ExecuteThreadID #16  | Skriptausführung: IPS_EVENTCONTROL.PHP ~ Absender: StatusEvent
13.06.2015 21:04:19.665 |     0 | CUSTOM  | IPS_EVENTCONTROL     | An Instanz '11108-Siemens_S7' ist Statusevent '102 - Active' aufgetreten !!
13.06.2015 21:04:19.665 | 36569 | DEBUG   | ExecuteThreadID #16  | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 24 ms


13703 - EventHandler  ==> bei aktiven WATCHDOG-Script
... diese Meldungen zwischen den Instanzenumkonfigurieren "ON THE FLY" auf, schut so aus als 
ob jeman zu langsam ist !! und die Variable (Statusvariable) in der Zwischenzit schon wieder nicht mehr existiert
==================================================================================================================
13.06.2015 06:19:00.827 |     0 | ERROR   | InstanceManager      | Fehler beim Verarbeiten von Nachricht: VM_UPDATE, Instanz 13073, Nachricht: Variable #13553 existiert nicht
13.06.2015 22:05:00.756 |     0 | ERROR   | InstanceManager      | Fehler beim Verarbeiten von Nachricht: VM_UPDATE, Instanz 13073, Nachricht: Variable #31010 existiert nicht

ACCESS_VIOLATION:
=================
03.06.2015 17:43:02.544 |     0 | ERROR   | ScriptEngine         | FunctionName: IPS_GetSnapshot, ThreadID: 5216, CrashReport: Access violation at address 0061B0A3 in module 'ips.exe'. Read of address 00000000
13.06.2015 06:53:01.436 |     0 | ERROR   | ScriptEngine         | FunctionName: WFC_GetSnapshot, ThreadID: 644, CrashReport: Access violation at address 0061AFE6 in module 'ips.exe'. Read of address 00000000

@PARESY,

Das Dienst stoppen mit Typ „Deltalogic Netlink Pro“ funktioniert noch nicht
Wann/wie wird der WATCHDOG-Script aufgerufen (bei mir nie), sollte der nicht auch bei „Reconnectversuch“ aufgerufe werden ?? ==> jedoch wenn ein Script konfiguriert erschein immer wieder mal eine Fehlermeldung im Log
Was mir auch aufgefallen ist, das der „IPS_STARTUP“-Script nicht immer der „erste“ Script noch dem Start ist, sondern das davor schon machmal Timerauslösungen passieren

@sunni2002,
kannst Du mal die Werte der „S7-Adressinstanz“ posten die du da mit „IPS_ApplyChanges“ sichern willst wenn die AccessViolation auftritt ==> ich ändere ständig die Instanzen und habe noch nie einen solchen Fehler bekommen

tgusi74

erwin · 14. Juni 2015 um 15:16

Hallo

Ich habe mit der Logo getestet -> funktioniert

Danke

sunni2002 · 14. Juni 2015 um 18:16

Hi,

Mal abgesehen vom „IPS_ApplyChanges“ … Ich bekomme diese Fehlermeldung wenn ich

unter I/O Instanzen die Siemens Instanz im Objektbaum öffne
den Haken bei „Aktiv“ raus nehme
auf übernehmen drücke
und anschließend den Haken wieder rein und auf übernehmen

Danach bekomme ich immer eine Fehlermeldung und die Verbindung wird nicht wieder aufgebaut.

Aktuell gerade wieder veruscht:

14.06.2015 18:09:27.611 | 36640 | WARNING | Siemens PLC          | Connection crashed. Trying to recover...
14.06.2015 18:09:27.624 | 36640 | ERROR   | EventControl         | Neuverbinden [Siemens S7] fehlgeschlagen = Access violation at address 007B2F67 in module 'ips.exe'. Write of address 00000000

tgusi74 · 14. Juni 2015 um 22:33

Bei mir zum Glück kein Problem,
Ich hab bei mir gerdae das ganze mit den Typen „ISO over TCP“ und „Deltalogic Netlink PRO“ getestet

Welche Typ der Verbindung benutzt / benötigtst Du bzw. sind bei Dir irgendwelche Abnormalen anderen Einstellungen nötig ??
Welche Steuerung und Adpater/CP ist bei Dir im Einsatz
Welches Betriebssystem benutzt Du

tgusi74

sunni2002 · 15. Juni 2015 um 07:58

Folgendes ist mir aufgefallen:

Habe eine komplett neue I/O S7 - Instanz angelegt. Keine Variable ist damit verbunden

Aktivieren und Deaktivieren der Verbindung erfolgt ohne Probleme
Habe einzelne Datenpunkte mit dieser Instanz verbunden. Zuerst einen Bool, dann 5 weitere Bools und einen Real Wert
Aktivieren und Deaktivieren der Verbindung erfolgt ohne Probleme
Habe mit diesem Skript alle Datenpunkte auf die neue Instanz umgehängt:

<?
$s7 = IPS_GetInstanceListByModuleID("{932076B1-B18E-4AB6-AB6D-275ED30B62DB}");   #  Alle S7-Instanzen holen
$NEWInst = 36766 /*[Siemens PLC2]*/; #  Neue S7-Intanz angelegt;

foreach ($s7 as $ids)   {
	$inst = IPS_GetInstance($ids);   # Instanzeigenschaft holen
	IPS_DisconnectInstance($ids);    	# Instanz Verbindung abbauen
	IPS_ConnectInstance($ids,$NEWInst); # Neuw Instanz Verbindung aufbauen
}

?>

Aktivieren und Deaktivieren der Verbindung führt wieder zu einem „Access violation at …“ Fehler

Das Ganze fühlt sich momentan so an, als ob irgendein Datenpunkt Probleme macht. Ist jetzt auch nur eine Vermutung … Ich werde mal weiter auf die Suche gehen. Vielleicht hilft diese Erkenntnis den Entwicklern ja weiter … :rolleyes:

EDIT: ------------------------------------
Habe jetzt mal von allen Instanzen den Status überprüft. Es liefern alle den Wert 102 zurück > also „Instanz aktiv“

Tabelle: Status der Instanz
Code Status
101 Instanz wird erstellt
102 Instanz ist aktiv
103 Instanz wird gelöscht
104 Instanz ist inaktiv

=200 Instanz ist fehlerhaft

Suche geht weiter …

EDIT: ------------------------------------
Habe nun sukzessive die Datenpunkte auf die neue I/O Instanz umgelegt. Folgende Erkenntnis:

Alles OK bei:

31 bool Variablen
2 integer Variablen
20 real Variablen

„Access violation at …“ Fehler bei:

31 bool Variablen
2 integer Variablen
21 real Variablen

Sobald ich einen Real - Wert mehr (also 21) habe tritt der Fehler auf. Habe die Real Instanzen untereinander verglichen. Passt auch. Einmal habe ich Variable A als 21igsten umgehängt und einmal die Variable B. Es lag also nicht am Datenpunkt selbst. Kann es sein das die Anzahl eine Rolle spielt?

Mit folgendem Skript habe ich Schritt für Schritt (Zahl bei IF erhöht) immer mehr Datenpunkte auf die neue Instanz umgehängt:


<?
$s7 = IPS_GetInstanceListByModuleID("{932076B1-B18E-4AB6-AB6D-275ED30B62DB}");   #  Alle S7-Instanzen holen
$NEWInst = 36766 /*[Siemens PLC]*/; #  Neue S7-Intanz angelegt;
#$NEWInst = 59274 /*[Siemens PLC2]*/; #  Neue S7-Intanz angelegt;

$idx = 0;
foreach ($s7 as $ids)   {
	$inst = IPS_GetInstance($ids);   # Instanzeigenschaft holen
	$var = IPS_GetObject($ids);
	$par = IPS_GetParent($var['ObjectID']);

	$var2 = IPS_GetVariable($par);
	$var2 = $var2['VariableValue']['ValueType'];

	$name = IPS_GetObject($par);
	$name = $name['ObjectName'];
	$par = IPS_GetParent($par);
	$par = IPS_GetParent($par);
	$cat = IPS_GetObject($par);
	$cat = $cat['ObjectName'];

#	print_r ($name);
#	echo "
".$name;
#	echo "
".$par;
#	print_r ($inst);
#	print_r ($var);
#	print_r ($var2);
#	echo "
".$var2;
	echo "
".$idx.": ".$inst['InstanceStatus']." --- ".$cat." --- ".$name." --- ".$var['ObjectName']." --- Typ: ".$var2;

	if ($idx <= 152 )   {
		IPS_DisconnectInstance($ids);    	# Instanz Verbindung abbauen
		IPS_ConnectInstance($ids,$NEWInst); # Neuw Instanz Verbindung aufbauen
 	}
	$idx ++;
}

?>

Keine Ahnung ob es damit zusammenhängt. Vielleicht ists ja ein Ansatz …

caesar · 15. Juni 2015 um 09:23

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

sunni2002 · 15. Juni 2015 um 09:38

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

tgusi74 · 15. Juni 2015 um 20:22

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,

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

tgusi74

caesar · 15. Juni 2015 um 20:46

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

mfg
cäsar

sunni2002 · 16. Juni 2015 um 08:47

Hi,

Welches OS: Windows8.1
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

tgusi74 · 16. Juni 2015 um 09:15

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)

sunni2002 · 16. Juni 2015 um 10:23

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).

tgusi74 · 16. Juni 2015 um 21:10

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 )

@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

sunni2002 · 16. Juni 2015 um 21:30

Hi tgusi74,

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

sunni2002 · 17. Juni 2015 um 21:27

… 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 …

tgusi74 · 18. Juni 2015 um 20:19

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

tgusi74