Hallo,

stop geht per Systemfunktion _changeOperationMode, oder per Systemvariable modeofoperation.

Um wieder nach RUN zu schalten geht das wieder per Variable modeofoperation.

Gruß

Christoph

Hallo,

das Abfangen kommt auf den Grund des Stops an.

Wenn man die SystemFaulttasks verwendet dann kann man eigentlich 90% der STOP Ursachen abfangen.

PeripherialFault Task -> Alle Fehler die mit Peripherie im zusammenhang stehen
TechnologicalFaultTask -> Alle Fehler die mit den Technologieobjekten zu tun haben
ExecutionFaultTask -> Alle Fehler die durch Anwenderprogramme verursacht werden können

Beiben dann noch solche Sachen wie Zeitüberlaufe, Systemfehler übrig.

Die TSI informationen in der ShutdownTask geben ebenfalls an warum der Übergang stattgefunden hat bzw. wodurch er ausgelöst wurde.

Gruß

Christoph

Hallo,

richtig weil das eine Zyklische Task ist und durch einen Programmfehler nicht sichergestellt ist das sie wieder Problemlos im Zyklus weiterläuft.

Das gleiche gilt auch für SynchronousTasks (IPO;IPO_2;IPO_Fast;Servo;Servo_Fast) und TimerInterrupttasks.

Die Gefahr das sie durch die Unterbrechung an der gleichen Codestelle wieder aufsetzt und den Fehler gleich nochmal hat ist da sehr groß.

Gruß

Christoph

Hallo,

dann ist die Antwort leider: NEIN.

Der Aufrufstack sollte im Diagnosepuffer eigentlich ohne Probleme auslesbar sein,
vom Anwenderprogram her nicht!
Zumindest die verursachende Stelle an der die AnwenderprogrammException aufgetreten ist.

Aber ich frage trotzdem mal nach wie oft es bei Dir vorkommt das eine Anwenderprogram Exception in einer zyklischen Task vorkommt und die CPU nach STOP geht.

Hast du wirklich so oft den Fall das auf ungültige Arrayindexe, Nulldivisionen oder FloatiingPoint execeptions gelaufen wird?
alle anderen Gründe für einen Start der ExecutionFaulttaks (Zugriffsfehler auf I/O oder TO Variablen; zugriff auf ungültige TO Instanzen) können Programtechnisch umgangen werden.

Gruß
Christoph

Hallo,

modeofOperation führt keinen Restart aus, daran kannst du zwar erkennen das sich der Betriebszustand geändert hat aber lediglich wieder nach RUN schalten (wenn das dann noch möglich ist) aber ein Restart geht darüber nicht.

Es gibt keinen Standardbaustein _FB_DebugTraceLineNumber, das ist ein Applikationsbaustein von 2007 für SIMOTION V4.0 weil es noch keine Debugmöglichkeit zu der Zeit gab.

Inwiefern der heute noch verwendbar ist kann ich nicht sagen.

Gruß

Christoph

AlexanderGalle

Das HMI kann automatisch Restart auslösen, indem es bei Wertänderung die Systemvariable modeofoperation auf RUN setzt.

 nein den das ist kein Restart sonder lediglich eine Betreibszustandsänderung!

Ein Restart ist ein neuanlauf der Baugruppe, sowas ist z.B. bei einem Zeitüberlauf notwendig dann kannst du so oft wie du willst den modeOfOperation auf Run steuern die baugruppe setzt ne BZ Sperre und kommt nicht nach run dann brauchst du einen Restart damit der RUN wieder möglich ist.

Hi,

es gibt einig Konfigurationsbefehle wie _activateDpSlaveAdress die einen Restart auslösen, einen direkten Befhehl gibt es so leider nicht.

Das würde in dem beschrieben Fall mit dem zeitüberlauf ja auch nichts nützen da im CPU Stop keine Programme laufen und damit auch keine Befehle ausführbar sind.

Auch eine Systemvariable an der CPU gibt es nicht die so etwas bewerkstelligt, hier bleibt dann letzen Endes nur das drücken des Reset Schalter oder Power OFF/ON vor Ort.

Gruß

Christoph

Hi,

habe ich noch nie probiert , nen versuch wäre es ja mal wert :)

Gruß

Christoph

Hallo,

per Systembefehl geht es nicht da dieser ja ur ausgeführt werden kann wenn die COU im RUN ist.
Im CPU STOP werden keine Programme ausgeführt.

Da geht es dann nur über die erwähnte systemvariable ModeOFOperation welche Du von der HMI aus schreiben kannst.

Gruß

Christoph