Skip to Content

Registrieren Anmelden

Industry Online Support

Technical Forum

Navigation

Mehrplatzsystem Scriptengine blockiert auf Client-Rechner

Erstellt von: vanDyk am: 17.09.2007 13:40 (16 Antworten)

Bewertung (0)

Dank 0

Result pages:: |; 1 | 2; |

17 Einträge

Einträge pro Seite: 10 | alle

17.09.2007 13:40	Bewerten (0)
vanDyk Gold-Mitglied Beigetreten: 17.09.2007 Letzter Bes: 17.04.2023 Beiträge: 799 Bewertung: (82)	Hallo, betreibe ein Mehrplatzsystem.Z.z. ein Server (Rack - PC IL43) und zwei WinCC Clients (ohne eigene Packages). in unregelmäßigen Abständen (dies kann mehrere Wochen dauern...) kommt es aus ungeklärter Ursachezum blockieren der Client RT (dies ist dadurch charakterisiert, dass sich an der Bedienstation keine Eingaben mehr tätigen lassen...). Der Rechner selbst ist noch intakt und lässt sich auch noch "ansprechen". Wirddann der Versuch unternommen, die RT zu deaktivieren so wird immer wieder angezeigt, dass noch eine Aktionin Arbeit ist. Im Endeffekt ist ein Neustart des Systems unumgänglich, um diesen Fehler zu beheben. Nach Tests im "Labormaßstab" erschien ein einziges mal auch "ExecutionError in ntdll.dll...." Im Script log stand dann irgend etwas Access - Violation on ...bla, bla meine Kenntnisse als Systemprogrammierer sind leider beschränkt. Vermutung1: Fehlerhaftes C Skript. Dummerweise läuft die Anwendung auf dem Server seit Monaten ohne dieses Problem (und auf meinem Entwicklungsrechner auch)!? Der Fehler trat bis jetzt grundsätzlich auf der Client Seite auf. Vermutung2: Fehlerhafte Netzwerkseinstellung...Gibt es eine von Siemensdefinierte Vorgabe, welche Einstellungen im NW zwingend erforderlich sind...? Vermutung3: Fehler in WinCC selbst? Hänge mal die verdächtige Script log Datei mit an... Hat jemand ein ähnliches Problem? Dateianhang SCRIPT.pdf (188 Downloads)
	VG / regards vanDyk
Vorschlag Bedanken Zitat Antwort

21.09.2007 11:10	Bewerten (0)
April Beiträge: 1776 Bewertung: (95)	Hi, klar Du hast irgendeinen Script Fehler. Zum Auswerten solltest Du Apdiag mitlaufen lassen. Dann kann man evtl. sehen, welches Script den Fehler verursacht. Viele Anregungen zur Fehlerauswertung findest Du unter dem Link http://support.automation.siemens.com/WW/view/de/22892165 Viel Erfolg April
April Beiträge: 1776 Bewertung: (95)
Vorschlag Bedanken Zitat Antwort

21.09.2007 12:52	Bewerten (0)
Fuschel Ausdauerndes Mitglied Beigetreten: 12.10.2005 Letzter Bes: 15.01.2024 Beiträge: 19 Bewertung: (2)	Hallo, hatte mal ein ähnliches Problem: Ich hatte in einem Script die Funktion "GetTagMultiWait" auf dem Client benutzt, um eine Variablenliste vom Server auf den Client zu kopieren. Dies hatte immer wieder in unregelmässigen Abständen zu "Hängern" geführt. "APDiag" hat hier nicht unbedingt weitergeholfen, es zeigte nur an, daß eine Aktion hängt. Es handelte sich jedoch immer um unterschiedliche Aktionen. Ich konnte den Fehler nur eingrenzen, in dem ich nach und nach die Aktionen deaktiviert hatte. Nach dem Eingrenzen und Ersetzen von "GetTagMultiWait" durch Einzel-GetTags (ohne "Wait") ist dieses Problem nicht mehr aufgetreten. Gruß Fuschel

Vorschlag Bedanken Zitat Antwort

21.09.2007 16:35	Bewerten (0)
vanDyk Gold-Mitglied Beigetreten: 17.09.2007 Letzter Bes: 17.04.2023 Beiträge: 799 Bewertung: (82)	Hallo, besten Dank für die Tipps! Ja, es scheint ein etwasvertrakteres Problem zu sein.Auf dem WinCCServer (unter Win 2003 Server R2) läuft alles ohne Aufhänger (auf meinem Entwicklungsrechner unter XP ebenfalls...). Daher glaube ich im Augenblick auch nicht so recht an ein direktes Scriptproblem. In den von ApDiag erzeugten log - Filesfindetkein direkterHinweis für eine fehlerhafte Scriptfunktion. Hab bis jetzt folgendes unternommen: 1.) ApDiag läuft auf allen Rechnern mit. Vom Siemens Support habe ich ein User - Dump - Tool erhalten, dies ist ebenfalls auf allen beteiligten Rechnern gestartet. 2.) Hab den WinCCPatch3 auf allen Rechnern installiert (hier war auch irgendetwas mit GetTag vers. GetTagWait...) Werde aber die GetTagWait Geschichte aus meinen Scriptenentfernen (im nächsten Schritt....um nicht die Übersicht zu verlieren) 3.) Frage: Habe folgendes (vermutlich unsauberes) Konstrukt in meiner Projektierung entdeckt:eine Checkbox istüber eine Variablenanbindung mit einer solchen verbunden. Gleichzeitig schreibt sie bei Änderung über eineDirektverbindung den aktuellen Wert der Checkbox in die gleich Variable.Sowas konnte doch unter ungünstigen Bedingungen eine Access Violation auslösen... oder? VG
	VG / regards vanDyk
Vorschlag Bedanken Zitat Antwort

19.10.2007 08:36	Bewerten (0)
sscheer Beiträge: 5 Bewertung: (0)	Hallo zusammen! Ich habe das gleiche Problem mit der ntdll.dll und dem Access Violation-Eintrag in der Logdatei, weswegen ich hierauf antworte und keinen neuen Beitrag erstelle. Die Probleme traten nach der Migration von WinCC 4.02 auf Version 5.1 auf. Laut Service-Request liegt das daran, dass "ab Version 5.1 die Skripte anders übersetzt werden". Auf die Frage: "Wie, anders?" bekam ich leider keine Antwort. Ich arbeite jetzt mit apdiag und versuche, den/die Fehler zu finden, indem ich alle Skripte mit printf()-Ausgaben beim Aufruf und Beenden des Skripts versehe. In einem Skript konnte ich hierdurch feststellen, dass ein einfacher strcpy()-Befehl nicht mehr ausgeführt wird, der in Version 4.02 keine Probleme machte. Kann mir hierauf jemand eine Antwort geben, die mir weiter hilft? Welche anderen Befehle werden jetzt auch nicht mehr ohne Weiteres abgearbeitet? Ich habe das (nicht laufende 5.1-er)Projekt gleich auf Version 6.0 migriert. Soll ich die Fehler besser zuerst in Version 5.1 beheben und dann erst auf Version 6.0 migrieren? Bin für jede Art von Hilfe dankbar! sscheer
sscheer Beiträge: 5 Bewertung: (0)
Vorschlag Bedanken Zitat Antwort

19.10.2007 10:38	Bewerten (0)
vanDyk Gold-Mitglied Beigetreten: 17.09.2007 Letzter Bes: 17.04.2023 Beiträge: 799 Bewertung: (82)	Hallo, habe vom Siemens Support ein(evtl. noch unveröffentlichtes) HF9 zugesand bekommen. Dieses habe ich zu Testzwecken erst einmal nur auf einem der Clientrechner installiert. Mal sehen, ob es was bringt.Sollte der Fehler nochmehreren Wochen nicht mehr auftreten, kann man vorsichtig optimistisch sein... In der Readme Datei zu diesem HFist folgendes zu lesen: Mit diesem Hotfix sind folgende Probleme behoben: HF5 -Bei einem Web Client können jetzt die Tastenkombinationen "Alt+F4", "Alt+Tab", "Ctrl+Esc" und "Alt+Esc" für die virtuelle Tastatur gesperrt werden. -Unter bestimmten Umständen konnte folgendes Verhalten auftreten: Meldungen, die im Meldesystem korrekterweise nicht mehr angezeigt wurden, standen im "EventState" der Variablen noch an. Dieses Verhalten konnte auftreten, wenn zum Baustein gehörige Meldungen gesperrt und anschließend freigegeben wurden. Dieses Verhalten wurde korrigiert. -In vereinzelten Fällen wurde die Bedienberechtigungsbox nicht im Vordergrund angezeigt. Dieses Verhalten wurde korrigiert. -ODK: Beim Anlegen von Strukturvariablen über ODK wurde die Stabilität der Funktion "GAPICreateTypInstance4" verbessert. -Wenn Sie in einem STEP 7-Projekt eine Operator Station ohne PC-Station anlegen, dann kann diese AS-Verbindung auch für die Funktion "OS übersetzen" ausgewählt werden. -Bei DualCore- oder Multi-Prozessor-Systemen konnte es in Ausnahmefällen zum Blockieren des Runtime-Starts kommen. Dieses Verhalten wurde beseitigt. HF8 -Der Hörmelder funktioniert jetzt auch nach Migration eines WinCC-Projekts. Beachten Sie, dass der Editor "Hörmelder" nach einer Migration einmalig geöffnet werden muss. Dies bewirkt, dass die beiden Variablen "@HornSettingTagsActive" und "@HornTriggeringSignalsActive" mit dem Startwert "1" versorgt werden. -Wenn im WinCC Alarm Control im Kurzzeitarchiv nach einem Meldetext selektiert wurde, dann wurde in seltenen Fällen neu eintreffende Meldungen nicht angezeigt. Dieses Verhalten wurde korrigiert. -Die Migration eines Projekts konnte in seltenen Fällen dazu führen, dass VBS-Skripte nicht mehr korrekt bearbeitet wurden. Dieses Verhalten wurde korrigiert. -Wenn bei der Benennung von Variablengruppen nationale Sonderzeichen benutzt wurden, z. B. Umlaute, dann war der WinCC Explorer nach einer Aktivierung von Runtime nicht mehr bedienbar. Dieses Verhalten wurde korrigiert. -Wenn beim wiederholten Öffnen eines OS-Objekts mit dem SIMATIC Manager keine Netzwerkkarte vorhanden war, dann konnte eine der beiden Meldungen auftreten: "OS übersetzen (302:203) Ein WinCC-Projekt konnte nicht geöffnet werden." "s7omwinx das Öffnen des Projekts schlug fehl. Der Datenbankkontext existiert nicht oder ist ungültig." Dieses Verhalten wurde korrigiert. Sie können die betroffenen Projekte beliebig oft öffnen und schließen. - Die Migration eines WinCC-Projekts nach WinCC V6.2 konnte in seltenen Fällen dazu führen, dass Filter im Alarm Control nicht mehr korrekt arbeiteten. Dieses Verhalten wurde korrigiert. -Der Redundanzabgleich von internen Variablen in einem redundanten Einzelplatzprojekt wurde verbessert. -Wenn eine Verbindung im Variablenhaushalt den gleichen Namen wie eine enthaltene Variablengruppe hat, dann wurden die Variablen der Gruppe im Variablenauswahldialog nicht angezeigt. Dieses Verhalten wurde korrigiert. -Im Dialog "Eigenschaften Rechner" können Sie auf der Registerkarte "Parameter" eine der projektierten Sprachen als Runtimesprache festlegen. Diese Einstellung wurde für die Menüs und Symbolleisten nicht korrekt übernommen. Dieses Verhalten wurde korrigiert. -Bei japanischer WinCC-Oberflächensprache wurden im Alarm Control die Einträge in den Spalten "Datum" und "Status" abgeschnitten. Die Spaltenbreite wurde korrigiert, sodass die Einträge nun auch im Japanischen lesbar sind. -Im Japanischen wurde der Meldetext korrigiert, der bei Überschreitung einer Grenze angezeigt wird. -Je nach Zoomeinstellung konnte beim Kopieren von zusammengesetzten Objekten die Zuordnung der Verbinder verloren gehen. Dieses Verhalten wurde korrigiert. -Bei japanischer WinCC-Oberflächensprache war im Alarm Logging das Eingabefeld zur Selektion nach Zeit missverständlich beschriftet. Die japanische Übersetzung wurde korrigiert. HF9 - ODK: Ein mit MSRTSetInfotext() erzeugter Infotext wird auch in der Archivsicht angezeigt. - ODK: Mit der Funktion MSCSGroupGeneric() erzeugte Meldungsgruppen können Sie mit MSCSEnumGroup() auflisten. - Wenn Sie in Runtime auf eine Meldung in der "Alarm Oneline" (Leittechnische Option) doppelklicken, dann wird die Funktion "Loop in Alarm" korrekt ausgeführt. - ODK: Sie können bei der Funktion GAPICreateNewVariable dem Parameter zProjectFile auch einen Leerstring zuweisen. - Berechtigungsprüfungen bei bereichsspezifischen Freigaben funktionieren auch beim Einsatz der Option "SIMATIC Logon". - Die Ebeneneinstellung einer Gruppe wird an die Teilobjekte einer Gruppe vererbt. - Beim Duplizieren in Runtime mit dem Project Duplicator wird auch das Serverpackage kopiert. - Eine Blockade in User Archives wurde behoben. Anm.: Aha...welche? - Wenn Sie bei Client-Server-Systemen Variablen mit der Skriptfunktion "GetTag__" auslesen, dann wird der aktuelle Prozesswert korrekt erfasst. - Meldungen werden auch bei redundanten Einzelplatzprojekten korrekt angezeigt. - Die Migration der erweiterten Analoganzeige wurde verbessert. - Das Verhalten von redundanten Serverpaaren bei Verwendung von User Archives wurde verbessert. - Die Filterfunktion des Variablenauswahldialogs wurde verbessert. - OPC Alarm & Event berücksichtigt die Spracheinstellungen. - Am OPC-A&E-Client können auch Anwendertextblöcke dargestellt werden. - Bei der Migration werden die für den Hörmelder benötigten internen Variablen korrekt angelegt. //------------------------------------- an sscheer: mit strcpy() arbeite ich auch, habe dabei keine Probleme... (Überlege aber auch schon zur Sicherheit mit strncpy() zu arbeiten...) Tritt der Fehler im Zusammenhang mit User Archives auf? //------------------------------------- bis dahin... VG
	Zuletzt bearbeitet von: vanDyk am: 19.10.2007 10:48 VG / regards vanDyk
Vorschlag Bedanken Zitat Antwort

22.10.2007 06:29	Bewerten (0)
sscheer Beiträge: 5 Bewertung: (0)	Hallo, Danke für die Antwort! Ich nehme aber an, dass ich hier mit dem Hotfix nichts anfangen kann. Wir haben hier WinCC 6.0, SP3. das Hotfix ist bestimmt für 6.2, oder? Ich werde mich jetzt zumindest um SP4 bemühen, denke aber nicht, dass mir das viel helfen wird. zu den user archives: kann ich leider nicht sagen, ich hatte weder mit der projektierung noch mit dem betrieb der anlage etwas zu tun. bin nur praktikant, der eine "einfache" umstellung eines projekts von WinCC4.02 auf WinCC6.0 machen soll. zumindest kann ich sagen, dass einige der bilder mit user archives keine skripte enthalten. ich ging bisher davon aus, dass sich die fehler in den C-skripten verstecken. sollte ich denn auch wo anders suchen???
sscheer Beiträge: 5 Bewertung: (0)
Vorschlag Bedanken Zitat Antwort

22.10.2007 11:45	Bewerten (0)
vanDyk Gold-Mitglied Beigetreten: 17.09.2007 Letzter Bes: 17.04.2023 Beiträge: 799 Bewertung: (82)	Hallo, 1.)ja, wir verwenden WinCC in der Version 6.2 (daher wird das HF dir in dieser Hinsicht nicht viel helfen) aber vielleicht hat ja jemand das gleiche Problem mit WinCC6.2 2.)ja das denke ich auch, die Ursache für diesen Fehler ist -wenn -in den C-Scripten (Speicherfehler, Pointerprobleme etc.) zu finden... aber das Problem mit der access violation in ntdll.dll ist wirklichschwierig zu differenzieren. hätten wir eine richtige Entwicklungsumgebungmit denen wir die C - Programme bearbeiten, könnte man jagenau sagen, dass der Fehler definitiv in unserem Programm (Script) auftritt. (Würde ja im Debugger etc. angezeigt...) InunseremFall haben wir es (wenn ich das richtig verstanden habe...) mit C - Sript zu tun. D.h.innerhalb von WinCC muss es noch einenInterpreter oderähnliches geben...D.h. unsere Skripte laufen immer im Kontext von WinCC... Wenn also der Fehler in WinCC selbst steckt (z.B. pdlrt.exe), was soll man dagegen tun? (außer Speicherdumps ziehen und and den Support senden...) Siemens hatangeboten, sich die Scripte einmal anzusehen, dass ganze passiert dann aber im Rahmen eines kostenpflichtigen AVC - Supports... VG
	Zuletzt bearbeitet von: vanDyk am: 22.10.2007 11:47 VG / regards vanDyk
Vorschlag Bedanken Zitat Antwort

30.10.2007 07:06	Bewerten (0)
sscheer Beiträge: 5 Bewertung: (0)	vanDyk Hallo, [...] 2.)ja das denke ich auch, die Ursache für diesen Fehler ist -wenn -in den C-Scripten (Speicherfehler, Pointerprobleme etc.) zu finden... aber das Problem mit der access violation in ntdll.dll ist wirklichschwierig zu differenzieren. hätten wir eine richtige Entwicklungsumgebungmit denen wir die C - Programme bearbeiten, könnte man jagenau sagen, dass der Fehler definitiv in unserem Programm (Script) auftritt. (Würde ja im De*** etc. angezeigt...) InunseremFall haben wir es (wenn ich das richtig verstanden habe...) mit C - Sript zu tun. D.h.innerhalb von WinCC muss es noch einenInterpreter oderähnliches geben...D.h. unsere Skripte laufen immer im Kontext von WinCC... Wenn also der Fehler in WinCC selbst steckt (z.B. pdlrt.exe), was soll man dagegen tun? (außer Speicherdumps ziehen und and den Support senden...) [...] Hallo zusammen! Die ntdll.dll ist der Speichermanager von Windows. Je aktueller die Windows-Version, desto strenger ist die Speicherverwaltung und desto schneller werden Fehler im Programm gemeldet. Die ACCESS_VIOLATION tritt also z.B. beim Zugriff auf bereits freigegebenen Speicher auf und wird von Windows/von der ntdll.dll gemeldet. Das könnte evtl. sogar die unregelmäßigen Abstürze erklären, die vanDyk im 1. Beitrag beschrieben hat und bei mir auch auftreten? Somit muss man also doch alle Skripte überarbeiten, wenn die ntdll.dll eine ACCESS_VIOLATION wirft . Eine richtige Entwicklungsumgebung für C in WinCC wäre dabei echt hilfreich!!! Die in Version 6.0 kennt ja nicht einmal die Tabulatortaste . Da könnte sich SIEMENS mal was einfallen lassen... Gruß sscheer
sscheer Beiträge: 5 Bewertung: (0)
Vorschlag Bedanken Zitat Antwort

02.11.2007 10:13	Bewerten (0)
ateam Bronze-Mitglied Beigetreten: 08.12.2006 Letzter Bes: 27.11.2023 Beiträge: 170 Bewertung: (26)	Hallo zusammen, ich weis es ist ziemlich frustierend, wenn sporadische Abstürze auftreten! Ich würde trotzdem versuchen systematisch vorzugehen,wenn's geht: - wie "april"oben sagt "APDIAG" verwenden. - wie "fuschel" oben sagt das Problemeingrenzen!!! (... aber ein "Abhängen", Deaktivieren von Funktionen geht bestimmt nicht, da die Anlage läuft!) Die Methode mit den printf-Anweisung zu Begin und Ende eines jeden Skript sind auf jeden Fall hilfreich. Ich verwende immer noch zusätzliche prinf-Anweisungen im Funktionsrumpf mit selbst gewählten Info- bzw. Fehlernummern, damit ich weis, dass das Script auch richtig funktioniert. Bemerkung zu fuschel: Ich glaube nicht, dass es ein guter Weg ist, prinzipiell alle GetTagMulti-Aufrufe durch Einzel-GetTag-Funktionen zu erstezen. Vielleicht lags bei"fuschel" ja an dem Patch3 für WinCC (DualCore-Patch) oder an einem Programmierfehler in der GetTagMulti-Funktion. Die sind gar nicht so easy: !!!!Auch hier können Speicherfehler auftreten, wenn als Zieladressen jeweils keine 4 Byte für jede Variable reserviert werden!!! http://support.automation.siemens.com/WW/view/de/26710242 - Vielleicht ist ja auch an ganz anderer Stelle ein "Speicherfresser" ... hatte mal mit einem Data-Grid zur Anzeige von Datensätzen einer Datenbanktabelle so einen Effekt.Ich hatte damals mit "perfmon.exe" den Speicherfehler lokalisiert, indem ich immer bei BIldanwahl und Bildabwahl die Anzahl der belegten HANDLES untersucht hatten. Wir hatten festgestellt, dass immer ein HANDLE "offen" blieb, also der Speicher nicht wieder freigegeben wurde. Das hat dann, je nachdem wie oft das Bild mit demGrid aufgerufenwurde, zum"Einfrieren" der Graphics Runtime geführt. - Vielleicht ist ja irgendwo Speicher mit Sysmalloc bereitgestellt,und nicht wieder freigegeben???

Vorschlag Bedanken Zitat Antwort

|

Teile diese Seite:

Teile diese Seite auf...

Folgen Sie uns auf