TIA CPU 1516-3 hängt sich auf und erfordert komplettes übersetzen der Software

W

wsd

Level-1
Beiträge
15
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Schon zum zweiten Mal habe ich den Fall, dass mein Programm oder die Steuerung sich aufhängt und nicht da weiter macht wo sie soll.
Dann hilft nur noch komplettes übersetzen der Software (Analog zum Klassiker im TIA WinCC wenn z.B. ein Button nicht mehr funktioniert hilft nur noch komplett übersetzen).

Programmiert ist alles in SCL und alles sind nicht optimierte Bausteine.

Hier der Programmausschnitt wo der Aufhänger war:
Code: 
...
ELSIF "DeckDB".data[#deck].state = 9 THEN  // Belt referencing
        IF "DeckmoveRef"(belt := #deck) THEN
            "stateChange"(p_dst_state := 3,
                          p_state     := "DeckDB".data[#deck].state);
            "DeckOutfeedDB".deck[#deck].h_doorClose := true;
        END_IF;
...

Erklärung zum Ausschnitt:
Programmiert wurde mit state machines wo jeder Anlagenteil seinen eigenen Ablauf hat damit man eben undefinierte Zustände vermeiden kann. In diesen state 9 ("DeckDB".data[#deck].state = 9) wird nur an einem Ort gewechselt und dass das passiert ist nur möglich wenn die gleiche state machine im state 5 ist und eine weitere Vorbedingung erfüllt ist. Daher kann ausgeschlossen werden dass dieser Integervalue ständig hin und her springt, es ist de facto so dass er im state 9 ist.

Die Bedingung dass der state Wechsel in einen anderen state erfolgt ist einzig der Bool-Rückgabewert von "DeckmoveRef"(belt := #deck). Und ich glaube hier befindet sich der Hänger, denn diese Funktion wird nicht aufgerufen obwohl sie aufgerufen werden sollte.
Ich habe die Möglichkeit mein Programm zurückzusetzen (über eine weitere Funktion) wo halt das ganze Aufstart-Prozedere abläuft jedoch blieb ich immer wieder in diesem state 9 hängen. Es kann auch ausgeschlossen werden dass der verwendet index #deck einen Wert hat womit die Funktion "DeckmoveRef"(belt := #deck) nichts anfangen kann.

Da die Anlage schnellst möglich wieder laufen musste kam mir leider nicht in den Sinn DeckmoveRef() woanders auf zu rufen um zu schauen was passiert. Als ich nämlich ausschließen konnte dass nichts hin und her springt war mir klar dass ich die Software komplett übersetzen muss, denn was ähnliches hatte ich schon mal.

Daher meine Frage ob da jemand ähnliche Erfahrungen gemacht hat? Es kann nicht sein dass ich die Software komplett übersetzen muss und damit die SPS in Stopp bringe und zugleich noch alle Datenbausteine mit ihren Startwerten initialisiere.
 
vollmi schrieb:
mach doch mal n Zähler rein nach dem Elsif um zu sehen obs da überhaupt reingeht. und speichere #deck dann gleich mal weg.
Zum Vergrößern anklicken....
Die Anlage musste halt wieder in Betrieb gehen daher konnte ich da nicht 10 Minuten rumspielen.. Aber #deck kann eigentlich nur 1..6 sein da die übergeordnete Funktion in einer Schleife 1 to 6 aufgerufen wird.

Mir schien es einfach als würde die SPS die Funktion DeckmoveRef() einfach ignorieren oder nicht aufrufen können. Daher habe ich mich gefragt ob etwas ähnliches schon mal bei jemanden von euch passiert ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber #deck kann eigentlich nur 1..6 sein da die übergeordnete Funktion in einer Schleife 1 to 6 aufgerufen wird
Zum Vergrößern anklicken....

Ist das eine FOR Schleife?

Wenn ja, eine For Schleife "z.B. FOR 1 TO 6" wird verlassen mit "7"

Daher würde ich die Werte mal sichern, welche da aufgerufen werden.


Evtl. habe ich dich auch missverstanden und der Code befindet sich innerhalb der Schleife
 
DeltaMikeAir schrieb:
Ist das eine FOR Schleife?
Wenn ja, eine For Schleife "z.B. FOR 1 TO 6" wird verlassen mit "7"

Daher würde ich die Werte mal sichern, welche da aufgerufen werden.
Evtl. habe ich dich auch missverstanden und der Code befindet sich innerhalb der Schleife
Zum Vergrößern anklicken....

Ich verstehe nicht ganz was du meinst aber der Programmausschnitt erhält die #deck Input-Variable von dieser FOR-Schleife:
Code: 
FOR #i := 1 TO "GlobalDB".amountOfDecks DO
wobei die Variable "GlobalDB".amountOfDecks den Wert 6 hat (auf diese Variable wird auch nirgends geschrieben, die ist fix im DB).
 
rostiger Nagel schrieb:
Ist den eine Zuweisung in einer „IF“ Anweisung möglich,
oder hängt sich die Steuerung deshalb auf.

Meiner Ansicht nach kein üblicher Syntax
Zum Vergrößern anklicken....

Doch das funktioniert. Wird so mehrfach verwendet und das auch schon seit Jahren (auch schon bei S7-300). Die Idee dahinter ist "saubere" Schnittstellen zu haben anstatt eine Variable auf einen Wert zu Vergleichen.
 
Wenn das Programm sich aufhängt, warum nicht einfach online gehen um zu checken warum es nicht weiter geht.
Es steht in irgendeiner Zustand und will nicht weiter. Sollte möglich sein zu finden ohne grossen Aufwand.
Schwierig ist wenn das Programm weiter läuft, und die Zustände und bedingungen nicht mehr zu sehen sind. Dann hilft nur loggen von die verdächtige Variabeln.
 
vollmi schrieb:
mach doch mal n Zähler rein nach dem Elsif um zu sehen obs da überhaupt reingeht. und speichere #deck dann gleich mal weg.
Zum Vergrößern anklicken....
JesperMP schrieb:
Wenn das Programm sich aufhängt, warum nicht einfach online gehen um zu checken warum es nicht weiter geht.
Es steht in irgendeiner Zustand und will nicht weiter. Sollte möglich sein zu finden ohne grossen Aufwand.
Schwierig ist wenn das Programm weiter läuft, und die Zustände und bedingungen nicht mehr zu sehen sind. Dann hilft nur loggen von die verdächtige Variabeln.
Zum Vergrößern anklicken....

Dein Vorteil ist, das Du sie wieder zum Laufen bringen kannst. Also erstell während sie läuft nen DB in welchem Die Zustände einmal gesichert werden per Merker. Den Merker triggern wenn sie das nächste Mal "hängt", nur einmalig, DB Aktual->Startwerte, Anlage neustarten und anschließend schauen was los war.
Wenn die Produktion so wichtig ist (ja, ist sie immer), dann bleibt kaum was anderes übrig. Der Schnipsel hilft leider nicht so arg viel.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
vollmi schrieb:
ouh mann. „Programm hängt sich auf“ liest sich für sps programmer als „cpu geht in stop“.
nichtsdestotrotz dafür sorgen das du die werte direkt vor dem „aufhängen“ wegsicherst um nachzuvollziehen was da abgeht.
Zum Vergrößern anklicken....

Ich hätte im OP sagen sollen dass sich die Steuerung aufhängt und nicht das Programm. Leider war ich unter Zeitdruck und musste so schnell wie möglich wieder in Produktion gehen.

JesperMP schrieb:
Wenn das Programm sich aufhängt, warum nicht einfach online gehen um zu checken warum es nicht weiter geht.
Es steht in irgendeiner Zustand und will nicht weiter. Sollte möglich sein zu finden ohne grossen Aufwand.
Schwierig ist wenn das Programm weiter läuft, und die Zustände und bedingungen nicht mehr zu sehen sind. Dann hilft nur loggen von die verdächtige Variabeln.
Zum Vergrößern anklicken....

Ich war Online auf der Steuerung und es gab keinen Anhaltspunkt dafür dass es nicht weiter geht. Vielleicht war ich nicht deutlich genug aber es liegt nicht am Programm. Die Anlage ist seit Wochen in Produktion und dieser Programmabschnitt wird täglich ausgeführt (und das bis heute morgen ohne Probleme). Außerdem läuft der gleiche Programmausschnitt auf vielen Anlagen und das seit Jahren...

Obwohl es nicht klar in meinem OP formuliert war, war die Kernfrage eigentlich ob jemand schon mal in die Situation gekommen ist wo nichts mehr hilft außer komplett übersetzen (Analog der WinCC Geschichte).
 
escride1 schrieb:
Dein Vorteil ist, das Du sie wieder zum Laufen bringen kannst. Also erstell während sie läuft nen DB in welchem Die Zustände einmal gesichert werden per Merker. Den Merker triggern wenn sie das nächste Mal "hängt", nur einmalig, DB Aktual->Startwerte, Anlage neustarten und anschließend schauen was los war.
Wenn die Produktion so wichtig ist (ja, ist sie immer), dann bleibt kaum was anderes übrig. Der Schnipsel hilft leider nicht so arg viel.
Zum Vergrößern anklicken....

Wie in meiner vorherigen Antwort bereits erwähnt wird dieser Programmausschnitt täglich aufgerufen und das ohne Probleme. Später als die Produktion in Pause ging habe ich vergeblich versucht das Problem zu reproduzieren. Das ist einfach möglich weil ich eine Schlüsselreset-Funktion (setzt komplette Anlage zurück und startet auf) die jedes mal die Funktion aufruft die zu diesem Programmausschnitt führt.

Ich habe (zum Zeitpunkt des Hängers) auch manuell die Bedingung hergestellt dass DeckmoveRef ein TRUE Rückgeben müsste was jedoch nicht geschehen ist.
 
Wenn das Programm hängt, und man schon weis ungefähr wo es hängt, dann kann es nur wenige Minuten dauern um näher zu checken warum es nicht weiter geht.
Wenn man die Ursache gefunden hat, kann man das Program resetten und in Ruhe und Freiden die Lösung finden und reinprogrammieren.

Die Verfahren mit die Zustände zu speichern wäre eine Möglichkeit. Aber dann muss man sicher sein dass man sämtliche relevante Variabeln abspeichert, und zwar auf die korrekte Zeitpunkt und Stelle (!) im Programm.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja gut, die Anlage rennt und rennt und nun kommt Variable X und schiesst dazwischen. Plötzlich geht nichts mehr. Aber wenn Du es weder mal eben reproduzieren kannst noch eine Beobachtung aufstellst kommst nur mit Glück dahinter.

Wenn Du die Bedingung manuell hergestellt hast das DeckmoveRef ein True hätte zurückgeben müssen es aber nicht tut, dann tipp ich schlicht darauf das der Teil nicht aufgerufen wurde, sonst hätte er es ja gemacht. Kann man das irgendwie prüfen?
 
escride1 schrieb:
Ja gut, die Anlage rennt und rennt und nun kommt Variable X und schiesst dazwischen. Plötzlich geht nichts mehr. Aber wenn Du es weder mal eben reproduzieren kannst noch eine Beobachtung aufstellst kommst nur mit Glück dahinter.

Wenn Du die Bedingung manuell hergestellt hast das DeckmoveRef ein True hätte zurückgeben müssen es aber nicht tut, dann tipp ich schlicht darauf das der Teil nicht aufgerufen wurde, sonst hätte er es ja gemacht. Kann man das irgendwie prüfen?
Zum Vergrößern anklicken....

Wenn man im state 9 ist wird die Funktion unweigerlich aufgerufen. Das passiert ja nicht nur einmal sondern durchs Band - die state machine wird in einer FOR-Schlaufe abgearbeitet und wird zwingend immer durchlaufen.
Die Schlaufe selbst wird ja von 1 bis 6 durchlaufen und daher hatte ich 6 sogenannte "Decks" die alle im state 9 hängen geblieben sind.
Für mich sah es so aus als würde es die Funktion DeckmoveRef einfach nicht geben für die SPS. Das konnte man ja mit Step7 machen mit dem Teilladen von Bausteinen. Aber mit dem konsistenten Laden von TIA ist das nicht mehr möglich.
 
wsd schrieb:
Wenn man im state 9 ist wird die Funktion unweigerlich aufgerufen. Das passiert ja nicht nur einmal sondern durchs Band - die state machine wird in einer FOR-Schlaufe abgearbeitet und wird zwingend immer durchlaufen.
Die Schlaufe selbst wird ja von 1 bis 6 durchlaufen und daher hatte ich 6 sogenannte "Decks" die alle im state 9 hängen geblieben sind.
Für mich sah es so aus als würde es die Funktion DeckmoveRef einfach nicht geben für die SPS. Das konnte man ja mit Step7 machen mit dem Teilladen von Bausteinen. Aber mit dem konsistenten Laden von TIA ist das nicht mehr möglich.
Zum Vergrößern anklicken....

ELSIF "DeckDB".data[#deck].state = 9 THEN // Belt referencing
IF "DeckmoveRef"(belt := #deck) THEN
"stateChange"(p_dst_state := 3,
p_state := "DeckDB".data[#deck].state);
"DeckOutfeedDB".deck[#deck].h_doorClose := true;
END_IF;
elsif - wenn nicht vorher irgendeine andere Bedingung wahr wurde wird diese nicht aufgerufen. Möglich das das vorkommt?

Ich würds ändern:

vor der IF-Anweisung:
Code: 
Merker1:=false;
Merker2:=false;
Code: 
ELSIF "DeckDB".data[#deck].state = 9 THEN // Belt referencing
        Merker1:=true; // Wurde dieser Zustand wahr?
        IF DeckmoveRef"(belt := #deck) THEN
                Merker2:=true; // Wurde dieser Zustand wahr?
                "stateChange"(p_dst_state := 3,
                               p_state     := "DeckDB".data[#deck].state);
                "DeckOutfeedDB".deck[#deck].h_doorClose := true;
       END_IF;

Dann siehst Du ob der ELSIF-Zweig aufgerufen wurde via Merker1 und ob die zweite Bedingung erfüllt ist mit Merker2. Vielleicht ist belt ja garnicht #deck?


Sonst seh ich so nichts, wie erwähnt - zuwenig Schnipsel für meinen Geschmack.
 

Similar threads

A
Serielle Kommunikation TwinCAT3 mit Beckhoff CX2030 und EL 6001
Antworten
3
Aufrufe
3K
StructuredTrash
S
Zurück
Oben