Sicheren Zustand bei Programmfehler gewährleisten

S

suud

Level-1
Beiträge
24
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wie läßt sich denn am besten eine Art Watchdog-Task/Programm implementieren, dass im Falle eines Fehlers im Haupt-Task (also wenn er sich z.B. in einer Endlosschleife befindet) sicherstellt, dass bestimmte Geräte in einen definierten Zustand gebracht werden.
Gibt's da eine besonders elegante/sichere Methode, z.B. über die Verwendung von Bus-Controllern statt Bus-Kopplern o.ä?
Oder hat TwinCAT dafür vielleicht schon irgendwelche Funktionen vorgesehen?
 
Üblicherweise haben Echtzeit-Systeme wie CoDeSys eine Zykluszeitüberwachung. Sprich: wenn das Programm in einer Endlosschleife hängen bleibt wird diese auslösen und die CPU stoppen (oder wie das bei CoDeSys auch immer heißen mag). Üblicherweise programmiert man zyklische Tasks auch so, dass man damit keine Endlossschleifen produzieren kann (also z.B. keine while-Schleifen).
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Nur wenn die CPU stoppt sind auch alle Ausgänge inaktiv. Ich muss aber
betimmte Ausgänge schalten wenn das geschieht. Also z.B. müssen Ventile unbedingt zugefahren werden und dafür muss das entsprechende Signal an den Motor weitergegeben werden.
 
Da bleibt mir nur 1 Vorschlag:
- Programm so verfassen, dass keine Endlosschleifen auftreten können!
Falls dies nicht möglich ist: Ventiltechnik oder Motore so ausführen, dass der stromlose Zustand der "sichere" ist. (evtl. Backup-Schaltungen per Hardware).

Das Thema hatte ich ehrlich gesagt noch nie! Sogar wenn ich in die Verlegenheit gekommen bin, while-Schleifen zu verwenden, gabs immer programmtechnische Möglichkeiten, um das Festlaufen in einer Endlosschleife zu verhindern.

Um was für eine Anwendung handelt es sich denn?
 
Also jetzt mal grundsätzlich:
Du solltest grundsätzlich davon ausgehen, das die SPS jederzeit plötzlich und unerwartet
auf Stop springen kann, wenn dann ein sicherer Zustand notwendig ist, der über das wegschalten der Ausgänge
hinausgeht musst du das ganze unbedingt extern per Hardware lösen.

Ich bin mir irgendwie auch gar nicht wirklich sicher, ob wenn wirklich ein Task "festhängt",
das dann überhaupt noch ein anderer Task läuft, bzw. spätestens ab dem endgültigen Auslösen des Watchdog,
läuft definitiv nichts mehr, es sei denn Beckhoff unterscheidet sich in dem Punkt von jedem anderen SPS-Hersteller,
aber das will ich jetzt so auch nicht glauben.

Allerdings speziell der Punkt Zykluszeitüberschreitung wird mit einem guten, robusten Programmaufbau nie passieren.

Mfg
Manuel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da ist was dran... dann muss ich das wohl anders lösen.
Das mit den Schleifen ist ein Punkt an den ich so noch garnicht gedacht habe. Es kommt bei mir zwar nicht auf Echtzeit an, aber ich denke mal, man sollte dann bei einer SPS wohl trotzdem möglichst immer versuchen Schleifen zu vermeiden und statt dessen alles rein Zyklusorientiert zu implementieren. Also statt einer For-Schleife nimmt man einen Bausteininternen Counter und setzt als Output ein Flag wenn die Berechnung oder was auch immer fertig ist?
 
Also wenn "For-Schleifen" ein wenig mit bedacht eingesetzt werden,
stellen diese bei einem relativ schnellen System wie Beckhoff sicherlich kein Problem dar,
schon gar nicht muss man unbedingt auf Sie verzichten ...

Schleifen belasten halt allgemein die Zykluszeit relativ Stark, im Vergleich zur sequentiellen Abarbeitung über mehrere Zyklen.

Wirklich gefährlich sind z.B. While Schleifen, hier muss man auf jeden Fall Vorsorge treffen das die Schleife halt notfalls abgebrochen wird.

Mfg
Manuel
 
Dem ist nur noch hinzuzufügen, dass die meisten aktuellen Systeme die möglichkeit bieten, Tasks mit geringer Priorität aber großzügiger Zykluszeitüberwachung zu programmieren.

Bei B&R z.B. ist dies die Tasklasse #8. Diese hat die niedrigste Priorität und wird daher vom "zyklischen" Programm (tc #1 - #7) immer wieder unterbrochen. Vom zyklischen Programm wird ein Startsignal gesetzt, die aufwändige Berechnung läuft im niederprioren Task und setzt eine Fertigmeldung an den zyklischen Task.

Trotz niedriger Priorität dürfen aber trotzdem keine Endlosschleifen zustande kommen. Aber man muss nicht krampfhaft die Berechnung sequentiell über mehrere Zyklen durchführen - das System verkraftet so schon mal FOR-Schleifen, die sich über 1-2 ms ziehen.

mfg Maxl
 
Schleifen zur Abarbeitung von Prozessen sind verboten. Einzig FOR-Schleifen für die Iteration über Arrays sind sinnvoll. Alles muss man mit State-Machines oder Automaten hinbekommen.

TwinCat kann Variablen mit einem Standartwert versehen. Das wird bei der Deklaration der Variablen gemacht. Wenn das nicht reicht, dann muss die Hardware den Rest gewährleisten. Das dürfte der Fall sein, wenn z.B. das BUS-Kabel beschädigt wird.
 
suud schrieb:
Nur wenn die CPU stoppt sind auch alle Ausgänge inaktiv. Ich muss aber
betimmte Ausgänge schalten wenn das geschieht. Also z.B. müssen Ventile unbedingt zugefahren werden und dafür muss das entsprechende Signal an den Motor weitergegeben werden.
Zum Vergrößern anklicken....
Das hängt von den Einstellungen der E/A-Komponenten ab! Welche E/A-Komponenten habt ihr?
Bei Buskopplern kann man das Verhalten parametrieren (Watchdog).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
suud schrieb:
Wie läßt sich denn am besten eine Art Watchdog-Task/Programm implementieren. Ich möchte gerne mit einem Programm in einem anderen Task überwachen, ob mein Haupt-Task noch läuft. Wenn er nicht mehr läuft, sollen bestimmte Geräte in einen sicheren Zustand gebracht werden (z.B. Ventile zufahren).
Zum Vergrößern anklicken....
Bei TwinCAT hängt es auch von den Prioritäten ab. Ich glaube, die höchstpriore Task MUSS immer laufen, wenn die als sog. "Sync Task" für den Feldbus dient. Wenn diese Task stoppt, stoppt auch der Bus. TwinCAT nutzt i.d.R. die höchstpriore Task als solche.
Das kann man aber irgendwo im Prioritätsmanagement einstellen.

Die Reaktion des Feldbus ist wie gesagt je nach verwendeter Hardware konfigurierbar.
Schau mal z.B. hier:
http://infosys.beckhoff.com/index.php?content=content/1031/bc3150/html/bt_bx config k-bus.htm
So ähnlich lässt sich jeder Buskoppler parametrieren.
 
um bei programmfehlern einen sicheren zustand zu erhalten muss es hardware mäßig gemacht werden! es könnte ja auch sein, dass die cpu komplett abschmiert und dann hättest du wieder ein problem!
 
trinitaucher schrieb:
Das hängt von den Einstellungen der E/A-Komponenten ab! Welche E/A-Komponenten habt ihr?
Bei Buskopplern kann man das Verhalten parametrieren (Watchdog).
Zum Vergrößern anklicken....

Wir haben die EK1100. Das mit dem Watchdog habe ich gefunden, aber das scheint mir nicht ganz das zu sein was ich suche?!

um bei programmfehlern einen sicheren zustand zu erhalten muss es hardware mäßig gemacht werden! es könnte ja auch sein, dass die cpu komplett abschmiert und dann hättest du wieder ein problem!
Zum Vergrößern anklicken....
Stimmt natürlich, ich muss das einfach nochmal mit unserem E-Techniker besprechen. Es kann aber auch nicht schaden, das alles gleich an mehreren Stellen abzusichern.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Könnte man denn nicht einfach einen Bus-Controller als Backup-SPS nehmen und diesen die entsprechenden Ausgänge ansteuern lassen, wenn ein bestimmtes Eingangs-Signal nicht mehr ansteht?
Ich sehe eigentlich nichts was dagegen spricht.
 
du musst immer daran denken, dass auch diese sps abschmieren kann..... bzw es kommt teurer 2 sps laufen zu lassen, als es hardware mäßig zu machen
 
Naja, die Mehrkosten dürften bei uns im Vergleich zum Gesamtspreis kaum in's Gewicht fallen. Und eine rein mechanische Lösung kommt leider nicht in Frage.
 
Zurück
Oben