Thema Step7 und Echtzeit

thwe

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

ich habe hier mal eine rein theoretische Frage zum Thema Step7 und Echtzeitfaehigkeit. (Mit Echtzeitfaehigkeit soll dabei die Vorhersagbarkeit der [maximal] benoetigten Zykluszeit eines Step7-Programms gemeint sein.)
Ich habe gelesen, dass Step7 echtzeitfaehig sei und habe mir daher einmal die Step7-Spachkonstrukte angeschaut. Aufgefallen sind mir dabei Sprungoperationen (speziell Rueckspruenge), die es (meiner Meinung nach) unmoeglich machen Endlosschleifen oder den Zeitbedarf einer Schleife vorherzusagen (z.B. eine Abbruchbedingung, die von einem Eingangswert abhaengig ist...).

Wie wird in Step7 die Echtzeitfaehigkeit garantiert? Ein reiner Abbruch durch einen Zykluszeitwatchdog ist ja auf jeden Fall keine Echtzeitfaehigkeit...
 
Ok, also Hintergrund ist eine Diplomarbeit im Bereich Informatik zum Thema "Sprachkonstrukte fuer Echtzeitsysteme". Dabei soll unter anderem betrachtet werden, welche allgemein ueblichen Sprachkonstrukte nicht echtzeitfaehig sind (also fuer die man nicht garantieren kann, dass sie in Zeit x abgearbeitet sind). Eine besagte While-Schleife oder ein Ruecksprung im Code koennen unter anderem so ein KO-Kriterium sein (falls die Abbruchbedingung nicht vorhersagbar ist).
Zu Step7 habe ich gerade wegen der zugesicherten Echtzeit gefunden (die fuer Prozesssteuerung ja zwingend notwendig ist).

Gewundert hab ich mich nur, dass Schleifen innerhalb eines Zyklus erlaubt sind. Daher bin ich gerade etwas ratlos, wie bei Step7 trotzdem Echtzeitfaehigkeit realisiert wird. Dem Stichwort Weckalarm werde ich auf jeden Fall mal nachgehen.

Ueber weitere Tipps wuerde ich mich freuen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
die auslegung ist aber auch falsch, denn eine endlosschleife tritt ja nicht auf!

schleifen sind möglich und können berechnet werden.
es kann also eine maximale ausführdauer bestimmt werden.

Na - ja ...
was machst du, wenn du verschachtelte Schleifen (mit variabler Breite) hast oder einen Sortier-Algorythmus ?

@thwe:
Wenn dir die Funktion "Weckalarm" (OB35 ...) ausreicht, dann ist auf diese Weise natürlich für bestimmte Funktionen durchaus eine Art Echtzeitfähigkeit zu erreichen. Es empfielt sich allerdings nicht, sein Priogramm nur auf diese Bausteine aufzubauen ...

Gruß
LL
 
Na - ja ...
was machst du, wenn du verschachtelte Schleifen (mit variabler Breite) hast oder einen Sortier-Algorythmus ?

eine handelsübliche schutzbeschaltung?!

die maximale anzahl an sortiervorgängen kann genauso bestimmt werden wie die schachtelung von schleifen sinnvoll und einfach überwacht werden kann. man muß halt nur dran denken und nicht einfach ins blaue hinein programmieren - "nach mir die sinflut"
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eigentlich ist doch vollkommen egal, wie lange die Zykluszeit des SPS-Programmes ist,
wichtig ist doch nur, das innerhalb einer angemessenen zu definierenden Zeit eine Reaktion erfolgt.

Echtzeit ist also irgendwas zwischen wenigen us (z.B. Airbag im Auto) und mehreren Sekunden (z.B. träger Temperaturregler).

Insofern ist alles Echtzeit ...

Mfg
Manuel
 
Insofern ist alles Echtzeit ...

Ist die Dauer eines Vorgangs (auch eine Wartezeit) vorhersehbar, dann spricht man von Echtzeit.

sofern du sie bestimmen kannst, hast du recht

@larry:

wenn es sich um eine variable liste handelt, die es zu sortieren gilt, kann man das sicher auch während der laufzeit machen, ja.

z.b. bei bubble sort ist die anzahl der nötigen (erwarteten) vertauschungen 1/4(n²-n) mit n...anzahl der elemente
 
die auslegung ist aber auch falsch, denn eine endlosschleife tritt ja nicht auf!

schleifen sind möglich und können berechnet werden.
es kann also eine maximale ausführdauer bestimmt werden.

Endlosschleifen sind nicht möglich? Also in Pseudocode würde mir spontan sowas einfallen:

BEGIN zyklus:

LABEL: loop
READ Input e0.0
IF e0.0 != 42
GOTO loop

END zyklus

Falls am Eingang e0.0 nie eine 42 anliegt, so hat man doch eine klassische Endlosschleife. Nach meinem bisherigen (rein auf Büchern basierendem) Verständnis von Step7 würde sich bei Überschreiten der Zykluszeit der Zykluswatchdog melden und die SPS in STOP-State versetzen. Liege ich damit erstmal korrekt, oder sind derartige Ausdrücke garnicht möglich?

Das ist zwar ein wirklich sinnloses Beispiel, aber es drück denke ich genau das Problem aus, was ich bei der Sache sehe. Eine Schleife, die nicht auf das Ende einer (verhersagbaren) Berechnung wartet, sondern auf ein spezielles (zufälliges) Eingangssignal.

Echtzeit soll wirklich nur bedeuten, dass ich vor Ablauf des Zyklus weiß, wann dieser enden wird. Wie schnell die reale Berechnung dabei ist, ist eigentlich egal. Echtzeit kann durchaus echt Zeit kosten... Nicht alles ist Echtzeit, sondern nur die Prozesse, deren (maximale) Laufzeit ich auch 100% verhersagen kann.

Danke für die vielen Beiträge. Ich kann mich leider zur Zeit mit SPS und deren Programmierung nur auf dem Papier beschäftigen (daher auch nur Pseudocode), von daher freue ich mich über reale Erfahrungsberichte und Anregungen umso mehr.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
BEGIN zyklus:

LABEL: loop
READ Input e0.0
IF e0.0 != 42
GOTO loop

END zyklus

ein solcher code macht in einem zyklisch abgearbeiteten programm keinen sinn und wird dir deshalb wohl nie in einer SPS begegnen (mal abgesehen davon, dass ein bit nur true oder false sein kann :rolleyes:)

schleifen werden vorwiegend für algorithmen verwendet, die innerhalb eines zyklusses abgearbeitet sein müssen, wie z.b. sortierungen oder fifo-register.

dein code würde im ersten zyklus in dem die bedingung nicht erfüllt ist, die zykluszeit überschreiten, da das prozessabbild nur vor beginn eines zyklusses aktualisiert wird und einen ganzen programmablauf gültig ist.

eine möglichkeit wäre die verwendung von azyklisch gelesenen eingängen, aber ... hmmm, das macht doch keiner :rolleyes:
 
Also Echtzeitfähigkeit muß ja nicht zwangsläufig bedeuten, daß dein Programm, welches du schreibst auch wirklich echtzeitfähig ist. Wenn du in einem Betriebssystem, welches echtzeitfähig ist, ein Programm schreibst, daß sich in einer Endlosschleife dreht, dann reagiert diese Teil des BS auch nicht mehr, ist also nicht echtzeitfähig, der Rest aber schon. Ich weiß ja nicht, wie Siemens die Echtzeitfähigkeit genau begründet, aber da das Hauptprogramm der SPS ja faktisch nur aus einem Task besteht, kann man diesen per Programm natürlich unberechenbar machen. allerdings hat die SPS ja noch Weckalarme etc. Diese Teile laufen in ihrem Zeitschema normal weiter.
 
Öhm....Echtzeitfähig bedeutet doch meines Wissens die Sicherstellung einer Reaktion innerhalb einer bestimmten Zeit. Eben nicht wie Windoof, was wenn es abstürzt, oder der gerfragte Task, gar micht mehr reagiert. Bei einer SPS wird das sichergestellt, indem ich eine Zykluszeitüberwachung habe und bei bestimmten Steuerungen (400er) eine Mindestzykluszeit einstellen kann. Wenn mein Programm also zwischen 8 und 14 ms braucht, stelle ich eine Mindestzykluszeit von 18ms ein und kann sicher sein, innerhalb von 54 ms gibt es eine Reaktion (von wegen PAE lesen, PAA schreiben und den Latenzen). Die Zykluszeitüberwachung stelle ich dann auf 50ms, dann gibt es eine Reaktion, sollte diese Zeit überschritten werden.
Genau deshalb gibt es ja immer noch SPSen, obwohl die schon seit 15 Jahren totgeredet werden. Klar gibt es auch schon lange Soft-SPSen, die das auch können, weil sie auf einem Echtzeitkernel laufen, also einem Betriebssystemteil, der sich ähnlich verhält wie eine SPS. Aber das macht er in einem HÜ-PC, der macht das keine 15 Jahre ohne Mucken, wie das eine SPS macht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
da trifft irgendwie theorie und wirklichkeit aufeinander. in der theorie mag eine SPS nicht garantiert echtzeitfähig sein, in der Realität gibt es aber wohl keinen erfahrenen SPS-Programmierer, der eine solche schleife im zeitkritischen teil programmieren würde.
evt. muß man das ganze auch andersrum betrachten:
ein prozess verlangt eine bestimmte reaktionszeit. wenn der prozess durch ein zyklisches programm gesteuert wird, ergibt sich daraus die max. zykluszeit (abtast-theorem beachten!). kann das programm die max. zykluszeit nicht einhalten, kommt es i.d.R. zum zykluszeit-fehler und zum cpu-stop. der stop-zustand gehört aber zu dieser betrachtung dazu. der stop-zustand stellt einen sicheren zustand dar, da definiert alle ausgänge abgeschaltet werden. damit wird der prozess angehalten (sofern dies möglich ist). dadurch erfolgt wiederum eine reaktion in einer definierten zeit und somit sind die echtzeit-kriterien erfüllt!
 
Mit Cyclic Interrupts hat S7 auch deterministische "tasks".
Bis 315 nur 1 task (OB35).
Ab 317 4 tasks (OB32..OB35)

Andere SPS hersteller haben auch nicht beliebig viele tasks.
Z.b. CompactLogix 4-8 tasks.
ControlLogix 100 tasks.
TwinCat 4 tasks.
 
kann das programm die max. zykluszeit nicht einhalten, kommt es i.d.R. zum zykluszeit-fehler und zum cpu-stop. der stop-zustand gehört aber zu dieser betrachtung dazu. der stop-zustand stellt einen sicheren zustand dar, da definiert alle ausgänge abgeschaltet werden. damit wird der prozess angehalten (sofern dies möglich ist). dadurch erfolgt wiederum eine reaktion in einer definierten zeit und somit sind die echtzeit-kriterien erfüllt!

Da der Prozess aber seine eigentliche Aufgabe nicht (in der vorgegebenen Zeit) erfuellen konnte, kann man nicht wirklich von einer Echtzeitausfuehrung sprechen. Sonst koennte man jede Sprache per Zeitscheiben echtzeitfaehig machen.
Ok, fuer die Praxis ist ja eigentlich auch nur interessant, dass in solch einem Fehlerfall eine kontrollierte Reaktion erfolgen kann. Fuer eine theoretische Betrachtung reicht mir das jedoch leider nicht aus. Das ist ledigleich ein (praxisrelevantes) Aufweichen der Echtzeitbedingung aber keine harte Echtzeit wie bei einer typischen Zustandsmaschiene mehr. (Das betrifft ebenso EZ-Betriebssysteme...)

Ich hatte gestern die Moeglichkeit mir bei ZF Brandenburg einen Getriebepruefstand mit SPS-Steuerung anzuschaun und ein paar Fragen zu klaeren. Dort hat man mich auch mit grossen Augen angeschaut, als ich von der besagten Endlosschleife gesprochen hab. "Wer wurede sowas machen?" - "Keiner!"
Nach ein wenig Diskusion (und Verteidigung wie toll ihre SPS alle laufen ;)) wurde ihren dann so langsam der eigentliche Hintergrund meiner Frage klar - Anschauen, mit welchen Techniken unkontrollierter Zeitbedarf (Extremfall Endlosschleifen) bei EZ-Maschinensteuerungen verhindert oder abgefangen werden um diese dann in (per Compiler) pruefbare Regeln fuer EZ-Sprachen umzuformen.

Bei praxisrelevanten Anwendungen scheint dies vergleichsweise leicht, da die Steuerungsaufgaben ueberschaubar und die Eingangsdaten bekannt sind (abgeschlossenes System). Im Bereich hoeherer Programmiersprachen und Betriebssysteme aber schon wieder nicht mehr, da eben alles mehr oder weniger nutzerbedingt unvorhersehbar auftreten kann (Interrupts, Speicheranforderung, ...).

Meine bisherige Vermutung lauft darauf hinaus, dass EZ nur in Form klassischer Zustandsmaschienen realisierbar ist. Generell zulaessig sind dann nur Schritte und Vorwaertsspruenge.
Mein Plan ist also eine Schrittweise Aufweichung bestehender Sprachkonstrukte, unter welchen Rahmenbedingungen der Zeitbedarf vorhersagbar bleibt. (Zum Beispiel koennten Rueckwaertsspruenge nur erlaubt sein, falls alle Eingangsbelegungen und Zuweisungen innerhalb der Schleife schon vor Abarbeitung bekannt sind.)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Meine bisherige Vermutung lauft darauf hinaus, dass EZ nur in Form klassischer Zustandsmaschienen realisierbar ist. Generell zulaessig sind dann nur Schritte und Vorwaertsspruenge.
Mein Plan ist also eine Schrittweise Aufweichung bestehender Sprachkonstrukte, unter welchen Rahmenbedingungen der Zeitbedarf vorhersagbar bleibt. (Zum Beispiel koennten Rueckwaertsspruenge nur erlaubt sein, falls alle Eingangsbelegungen und Zuweisungen innerhalb der Schleife schon vor Abarbeitung bekannt sind.)

kennst du S7-GRAPH. Damit werden in graphischer Form Schrittketten programmieren. Diese erfüllen alle Bedingungen, die du für EZ formulierst. Es ist dann nur eine Vorschrift für den SPS-Programmierer notwendig, NUR mit S7-GRAPH zu programmieren
 
Echtzeitfähigkeit bedeutet doch, dass Dein System in einer Zeit x reagieren kann. Programmieren mußt Du solche Geschichten doch sowieso selber. Die S7 garantiert Dir aber, (wie andere SPS-en wohl auch), dass Dein Programm aber z.B. nicht durch irgendwelche BS eigenen Prozesse unterbrochen wird.
Angenommen Du hast einen modernen PC und programmierst auf diesen eine einzige Schleife, von mir aus auch noch in Assembler. Die wird pro Sekunde wahrscheinlich ein paar Millionen mal durchlaufen. In dieser Schleife fragst Du einen Eingang ab, den Du nur 1 mal pro Sekunde benötigst. Also wäre das für diese Anwendung erstmal Echtzeit. Jetzt geht Dein BS (z.B. XP) hin, und greift auf die Festplatte zu. Während dieser Zeit friert XP alle anderen Prozesse ein. Und schon wars das mit der Echtzeit, weil XP vielleicht zwei Sekunden lang sämtliche Prozesse belegt. Somit könnte zwar Dein Programm die Echtzeit garantieren, das BS aber nicht.

So etwas kann Dir bei der S7 nicht passieren.
 
@thwe:
Bei deiner Betrachtung solltest du auch berücksichtigen, dass wenn die SPS zu Mess-Aufgaben (wie in deinem Beispiel) herangezogen wird man sehr wohl eine "echte" EZ-Fähigkeit duch Anwendung der Zeit-INT-OB's erreichen kann. Ich realisiere dann die Messwert-Aufnahme in dem Zeit-OB (der dann in dem von dir vorgegebenen Zeitraster aufgerufen wird) und kann mich auf die Zuordnung der Werte schon verlassen.

Bei der Betrachtung von Maschinen-Reaktionen ist EZ-Fähigkeit i.d.R. nicht so wichtig bzw. wird durch geeignete Sub-Hardware und/oder -Technik erreicht ...

Gruß
LL
 
Zurück
Oben