Beckhoff CX5120 anhaltende Bluescreens / BSOD

S

stseme04

Level-2
Beiträge
15
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
GELÖST: Beckhoff CX5120 anhaltende Bluescreens / BSOD

Guten Morgen!

Ich entwickle z.Zt. auf einer Beckhoff CX5120 mit Windows 7 Embedded (Standard) und Intel Atom CPU.

Letzte Woche hat das alles auch noch recht gut funktioniert, heute morgen geht die SPS jedoch nicht mehr in den RUN.
Genauer gesagt: sie fährt eine (gefühlte) halbe Minute hoch und stürzt dann ab.

Ein angeschlossener Bildschirm zeigte auf das Windows startet und es zeitnah, wenn das TC3 Logo erscheint, zu einem Bluescreen kommt. Leider ist dieser wenig hilfreich und besagt laut kurzer Internetrecherche einen Kernel Exception- (0x8E) und einen Invalid Process Attach Attempt-Fehler (0x05).


Frage daher: Hat jemand schon ähnliche Probleme gehabt und diese selbständig wieder gelöst oder soll ich die Steuerung einfach direkt einschicken? Versuche in einen "abgesicherten Modus" zu kommen schlugen leider fehl.

Über Hilfe und Anregungen wäre ich sehr dankbar!

Grüße
stseme
 
Zuletzt bearbeitet:
Hallo,

ich würde versuchen ein neues Image aufzuspielen. Kannst du vom Beckhoff FTP laden.

Grüße
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sollte das Windows-Image hinüber sein verbleibt dir nur der Weg das Image neu aufzuspielen (Kontakt Support/Service Beckhoff wenn du die Möglichkeit hast ein Acronis Image über einen CFast Reader auf die Karte zu spielen.
Sollte der PageFault aus der TwinCAT-SW bzw. deinem Projekt erzeugt werden (was wahrscheinlicher ist als der Punkt oben) dann kommst du über F8 in den abgesicherten Mode. Hier wird die TwinCAT nicht gestartet und du hast dann die Möglichkeit z.B. das c:\TwinCAT\3.1\Boot-Verzeichnis (für TC3) zu löschen und dann das Windows-System wieder reguläre zu starten.

Guga
 
Zunächst einmal vielen Dank für die Vorschläge!

Gerne würde ich zunächst ausprobieren ob das Problem mit löschen des Boot-Verzeichnisses behoben wird. Ich habe jedoch schon vor ein paar Tagen versucht in den abgesicherten Modus zu kommen und beim hochfahren wiederholt F8 gedrückt. Der angeschlossene Bildschirm bleibt jedoch schwarz, was die ganze Geschichte deutlich erschwert - habe es bisher dementsprechend nicht geschafft in den abgesicherten Modus zu kommen...
 
Wenn du einen CFast Karten Leser hast kannst du den Boot-Ordner auch direkt im Filesystem löschen.

Ansonsten ist auch das Image gleich aufgespielt wenn du einen BST Stick hast und keine Daten retten musst.

Grüße
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hab mir endlich einen CFast Reader besorgt und was soll ich sagen? Die Steuerung schnurrt wieder wie ein Kätzchen :cool:
Vielen Dank für den Tipp!

Zum Glück geht das bei meiner kleinen einfacher - MicroSD sei dank. Der Vorteil der Cfast liegt auf der Hand, aber die Reader sind selbst bei mir in der Firma noch etwas rar gesät.

Was ich davon halte, dass sich die Steuerung in einem solchen Falle nicht einfach in den STOP versetzt brauch ich ja nicht zu erwähnen?
 
stseme04 schrieb:
Was ich davon halte, dass sich die Steuerung in einem solchen Falle nicht einfach in den STOP versetzt brauch ich ja nicht zu erwähnen?
Zum Vergrößern anklicken....
Wie soll Sie das bitte tun? Die Steuerung selber ist ja vermutlich noch nicht gestartet, das TC3 Logo zeigt meines Wissens nicht an, dass der TC3 Dienst gestartet wurde. Die Ursache des Absturzes ist ja vermutlich ein zerschossenes OS und in solch einem Fall würden auch andere Steuerungen die Segel streichen ohne in den Stop zu gehen.
 
Naja, offensichtlich war die Absturz (Windows Absturz / BSOD) Ursache eine fehlerhafte Konfiguration bzw. ein fehlerhaftes TC3 Projekt. Mechanismen die verhindern das immer und immer wieder versucht wird eine fehlerhafte Konfiguration zu laden, im Bedarfsfall direkt auf STOP gehen ohne eine Konfiguration zu laden oder den TC Service vorübergehend deaktivieren, sollten kein Problem sein.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
stseme04 schrieb:
...
Was ich davon halte, dass sich die Steuerung in einem solchen Falle nicht einfach in den STOP versetzt brauch ich ja nicht zu erwähnen?
Zum Vergrößern anklicken....
Diese Diskussionen sind langsam echt mühselig.

Ein BSOD ist ein STOP bei dem Angezeigt wird, wo der Fehler war - nicht mehr und nicht weniger! Aus Rechner-Sicht gesprochen ist das ein definierter Stop-Zustand. "klassische" SPSen gehen, wie du geschrieben hast, ebenfalls in den Stop und auch diese muss man danach wieder neu Starten. Mit aktuellen Rechner dauert der Boot-Vorgang nur wenige Sekunden und somit nicht wesentlich länger als eine klassische SPS für einen Neustart benötigt. Bei Fehlern die zu einem BSOD geführt haben, wäre es sowieso ratsam die Steuerung einmal neu zu starten (selbst wenn man den Fehler mit eingeschaltenem Exception handler vielleicht abfängt). Den Grund für deinen BSOD kenne ich nicht, aber nehmen wir als BEISPIEL nur mal an du hättest mit Pointern in einen ungültigen Bereich geschrieben oder durch einen fehlerhaften Treiber. Wenn du dann einfach wieder auf Start klickst ohne die Steuerung neu zu initialisieren bekommst du ein nicht definiertes System-Verhalten und das wäre natürlich deutlich besser, oder?

Ich bin mir darüber im klaren das BSODs, so wie man sie von seinem Engineering-System oder PC kennt lästig sind und sehr negativ belastet. Aus Sicht der Steuerung ist das aber ein definierter Stop-Zustand des Rechners. Je nachdem wo er herkommt, kann man TwinCAT so einstellen, dass es einen BSOD überlebt und dann die Applikation noch gesichert runterfahren kann. Neu starten würde ich aber nach einem BSOD aus oben genannten Gründen selbst dann.

Und wie Oliver schon geschrieben hat, auch klassische SPSen gehen sofort immer in den Stop wenn man ein Fehlerhaftes Boot-Projekt runterspielt oder ein "Firmware"-Fehler vorliegt.
 
stseme04 schrieb:
Naja, offensichtlich war die Absturz (Windows Absturz / BSOD) Ursache eine fehlerhafte Konfiguration bzw. ein fehlerhaftes TC3 Projekt. Mechanismen die verhindern das immer und immer wieder versucht wird eine fehlerhafte Konfiguration zu laden, im Bedarfsfall direkt auf STOP gehen ohne eine Konfiguration zu laden oder den TC Service vorübergehend deaktivieren, sollten kein Problem sein.
Zum Vergrößern anklicken....

Wenn Fehler erkannt werden, kann man die Konfiguration auch nicht Aktivieren. Da TwinCAT aber ein sehr offenes System ist und viel zulässt ist es nicht immer einfach zu entscheiden ob das System falsch konfiguriert ist oder nicht. Was mehrere Neustarts hintereinander angeht, so gibt es Firmen die für alle Maschinen das selbe Projekt verwenden, egal ob sie gerade Gummibären oder LKWs produzieren. Die Hardware wird dann von der SPS erkannt und von dieser eigenständig aktivert oder deaktivert und dann das System neu gestartet. Je nachdem was alles der reihe nach während der Aufstartphase der Maschine durchgeführt wird, können das auch mal mehrere Neustarts sein. Wo ist dann also die Grenze? Nach zwei Kurz hintereinander folgenden Neustarts? oder wenn sich die Konfiguration der Maschine ohne Engineering-Zugriff ändert? Es gibt hier leider oder Gott sei dank kein schwarz-weiß! Das ist genau die Stärke von TwinCAT und ja - man muss definitiv auf diese System geschult sein und damit umgehen können.
 
Zuletzt bearbeitet:
Also irgendwie habe ich das Gefühl wir reden aneinander vorbei?
Gegen den BSOD an sich ist ja gar nichts einzuwenden, aber wenn ich in einer Boot-/BSOD-Schleife hänge, ist das alles andere als ein definierter Zustand??? Schließlich komme ich aus diesem "Zustand" nicht mehr heraus noch kann ich etwas unternehmen.

Es ist ja nicht so das ich mich jedesmal zur Steuerung verbunden und gesagt habe "los lad das kaputte Projekt", ich hatte keine Chance zur Fehleranalyse etc.
Wenn eine klassische SPS im Stop ist, kann ich trotzdem eine Verbindung herstellen - das war hier nicht der Fall - und genau da liegt doch das eigentliche Problem.
 
KGU schrieb:
richtig, der abgesicherte Modus sollte auf alle Fälle möglich sein um auch ohne Card-Reader das System zu bereinigen.
Zum Vergrößern anklicken....

Schön das wir doch noch zusammen finden.


Den vorherigen Post hatte ich überlesen, dazu würde ich noch anmerken wollen das eine "Grenze" wohl auch absolut kein Problem darstellen würde. Mir fallen unzählige Möglichkeiten ein wie ein solcher Sicherheitsmechanismus realisiert werden könnte ohne das man an Funktionalität einbüßt. Das ein simpler Zähler nicht ausreichend ist, sollte ebenfalls klar sein.

Ich bedanke mich nochmals bei den vorherigen Tippgebern und klinke mich hiermit aus der Diskussion aus, da jede weitere Antwort meinerseits noch weiter auf ein passiv-aggressives Niveau herabsinken würde.



Grüße und bereits ein schönes Wochenende an alle Diskussionsteilnehmer!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
stseme04 schrieb:
Wenn eine klassische SPS im Stop ist, kann ich trotzdem eine Verbindung herstellen - das war hier nicht der Fall - und genau da liegt doch das eigentliche Problem.
Zum Vergrößern anklicken....
Wie bei defektem OS? Auch eine Siemens oder ABB Steuerung streicht die Segel wenn deren OS einen Schlag hat und da kommst Du mit Sicherheit auch nicht mehr online. Der Vorteil einer Lösung bei dem das OS auf einem entfernbaren Datenträger liegt ist, dass man sich in einem solchen Fall selber helfen kann und nicht die ganze SPS zum Hersteller schicken muss.
 
oliver.tonn schrieb:
Wie bei defektem OS? Auch eine Siemens oder ABB Steuerung streicht die Segel wenn deren OS einen Schlag hat und da kommst Du mit Sicherheit auch nicht mehr online. Der Vorteil einer Lösung bei dem das OS auf einem entfernbaren Datenträger liegt ist, dass man sich in einem solchen Fall selber helfen kann und nicht die ganze SPS zum Hersteller schicken muss.
Zum Vergrößern anklicken....

Herrlich wie wir hier immer von einem Thema zum andern springen. Seit wann ist eine defekte Konfiguration (die im Boot Ordner liegt) gleich zusetzen mit einem defekten "OS" bzw. besser gesagt Firmware bei einer klassischen Steuerung?!
Du zitierst mich hier und sprichst von "Er" - kann dir also nicht folgen worauf du hinaus willst oder über wen du redest. Die Steuerung die ich benutzt habe, hatte das im ersten Post beschriebene Fehlerbild. Es wurden zwei mögliche Fehlerursachen genannt: Windows zerschossen oder fehlerhafte Konfig. Die Lösung meines Problems war, den Boot Ordner zu löschen. Danach funktionierte wieder alles einwandfrei. ERGO: fehlerhafte Konfiguration (ob durch Benutzer oder Übertragung sei dahingestellt). Mir ist bisher keine SPS untergekommen zu der ich keine Verbindung mehr aufbauen konnte nur weil die Konfiguration fehlerhaft war.
Zufällig arbeite ich für einen größeren Hersteller in der Automatisierungsbranche und habe deshalb mit diversen verschiedenen Steuerungen sämtlicher Hersteller u.a. für Integrationstests zu tun - klar dass man dann nicht alle Steuerungen in der Tiefe kennt wie ein Spezialist der sich jeden Tag mit nur einem Hersteller auseinandersetzt. Nicht das ich meinen Wissensstand hier vor irgendjemandem rechtfertigen müsste, ich will lediglich darlegen das ich in das Forum gekommen bin um Hilfe zu erhalten - nicht um eine Grundsatzdiskussion zu starten welche Steuerung nun besser ist oder um mir Unfähigkeit unterstellen zu lassen.

Da ich die Hilfe schon längst erhalten habe, könnte der Thread eigentlich auch geschlossen werden.
 
Hallo stseme04,
hier kurz ein paar Erklärungen warum meine Posts sind wie sie sind. Bezüglich des "Er" habe ich schlicht übersehen, dass Du der TE bist, sorry. Bezüglich Deiner Aussage das es nicht angehen kann, dass man nach einer beschädigten/falschen Konfiguration nicht mehr Online kommt kann ich nur bedingt zustimmen. Das eine beschädigte/falsche Konfiguration das OS zum Absturz bringt und man somit nicht mehr online kommt kann wirklich nicht angehen, 100% ACK dazu. Das man nach einer falschen Konfiguration nicht mehr online kommt obwohl die SPS ansonsten arbeitet sehe ich jedoch nicht unbedingt als Mangel an. Man kann bei TC3 verschiedene Protokolle konfigurieren und den Netzwerkkarten zuordnen. Diese Protokolle können dann jedoch verhindern, dass man über diesen Anschluss noch Online kommt. Sperrt man sich auf diese Art aus hat man selber Schuld, allerdings wäre eine Warnung auf diesen Umstand seitens der Entwicklungsumgebung nicht schlecht.
Last but not least, habe ich es irgendwie nicht begriffen, dass Du den Boot-Ordner gelöscht/geleert hast sonst hätte ich mir den einen oder anderen Post gespart, auch dafür sorry.
 
Zuletzt bearbeitet:

Similar threads

B
FSoE Adresse auslesen mit C# und Beckhoff TwinCAT.Ads .Net
Antworten
2
Aufrufe
7K
BXcool
B
Zurück
Oben