Echtzeit

A

Anonymous

Guest
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo an Alle!

Kann mir jemand erklären bzw. mittteilen ob es für den Begriff "Echtzeit" in Verbindung Steuerung und Visualisierung (Alarme) eine verbindliche Definition gibt?.

Ich habe das Problem dass immer wieder der Begriff Echtzeit verwendet wird aber bei hinterfragen des Begriffes plötzlich keiner so 100% sagen kann was es genau bedeutet bzw. in welchen Richtlinien bzw. Vorschriften dies definiert ist.

besten Dank im Voraus -> hoffe es ist auch hier kein endloses Thema

und sorry im voraus -> bitte keine Antworten die beginnen mit : Meiner Meinung nach .....
 
Echtzeit bedeutet nur, dass die maximale Zeit die benötigt wird, bis auf ein Ereignis reagiert wird, genau bestimmt werden kann. Dies sagt nichts aus über die Länge dieser Zeit.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

Echtzeit ist dann, wenn Deine Steuerung garantiert in einer maximalen Zeit auf ein Ereignis reagiert. Diese maximale Zeit hängt hier vom konkreten Prozess ab: bei Antriebssteuerungen u.U. im ms-Bereich, für die Temperaturregelung einer Wohnung reichen Reaktionszeiten im Minutenbereich.

Was geht in die Berechnung der Reaktionszeit ein:
-Erfassung und Übertragung der Meßwerte und sonstiger Eingänge (Übertragungszeit bei Feldbussen!!!)
-Programmbearbeitung (Zykluszeit der SPS)
-Ausgabe der Meßwerte, Reaktionszeit des Stellgliedes

Peter
 
Ich habe noch folgende Definitionen gefunden:

Echtzeit (Real-Time) ist die Fähigkeit eines Systems, eine bestimmte Aufgabe unter allen Bedingungen innerhalb einer definierten Zeitspanne zu erledigen.
Harte Echtzeit (Hard Real-Time) bedeutet, dass in 100% aller Fälle die zeitlichen Vorgaben eingehalten werden müssen.
Weiche Echtzeit (Soft Real-Time) bedeutet, dass nicht in 100% aller
Fälle die zeitlichen Vorgaben eingehalten werden müssen.
 
Die S7 arbeitet nicht in Echtzeit.

Nur die Weckalarmbausteine OB30- können so parametriert werden.

Andere Systeme, wie B&R und Beckhof, vieleicht alle codesyssteme? arbeiten mit festen Taskklassen, z.B. 10,20,50ms

pt
 
Zuviel Werbung?
-> Hier kostenlos registrieren
plc_tippser schrieb:
Die S7 arbeitet nicht in Echtzeit.
Doch, tut sie und auch im ganz normalen OB1. Und zwar deshalb, weil du die Ausführungszeiten aller Befehle und die Zeit für PAE lesen, PAA schreiben, addieren kannst und es somit eine obere Schranke der Ausführungszeit gibt.
Du mußt natürlich überall, insbesondere bei Sprüngen, die Worst-Case-Zeiten annehmen.
Natürlich kannst du die Echtzeitfähigkeit durch ungeeignete Programmierung aushebeln, z.B. durch Rückwärtssprünge, Schleifen, Rekursion.
Natürlich kann die garantierte maximale Ausführungszeit auch für eine konkrete Anwendung zu langsam sein.
Gäbe es keine obere Schranke der Ausführungszeit, würde schon die folgende einfache Anwendung hin und wieder schief gehen:
SPS schaltet Förderband ein und soll Förderband stoppen, wenn Fördergut in Lichtschranke eintritt. Da würde das Gut ab und zu wieder aus der LS herausgefördert, bevor das Band stoppt.
 
Zottel schrieb:
Doch, tut sie und auch im ganz normalen OB1. Und zwar deshalb, weil du die Ausführungszeiten aller Befehle und die Zeit für PAE lesen, PAA schreiben, addieren kannst und es somit eine obere Schranke der Ausführungszeit gibt.
Meines Erachtens nach nicht ganz. Die obere Grenze ist eher die Zykluszeitüberwachung. Der OB 1 läuft fast mit der niedersten Priorität und wird durch diverse Ereignisse unterbrochen. Je nachdem wie lange diese dauern und wie oft diese auftreten (Werckalarme, Interrupts, ..) verlängert sich entsprechend die Zykluszeit. Eine reine Addition der Ausführungszeiten des OB 1 und der aufgerufene Bausteine liefert somit zu kurze "Maximalzeiten".
 
Rainer Hönle schrieb:
Die obere Grenze ist eher die Zykluszeitüberwachung.
Die Überwachung könnte man auch jedem nicht-echtzeitfähigen Steuergerät hinzufügen. Aber daurch, daß man die Steuerung in Stop bringt, ist ja nichts gewonnen. Eher schon wird dadurch, daß die SPS im allgemeinen und bei einer Reihe von Tests die Zykluszeit nicht überschreitet, ein gewisses Vertrauen in die Eignung von Programm und Hardware erzeugt. Was aber streng genommen unzureichen ist.
Rainer Hönle schrieb:
Der OB 1 läuft fast mit der niedersten Priorität und wird durch diverse Ereignisse unterbrochen. Je nachdem wie lange diese dauern und wie oft diese auftreten (Werckalarme,
Von Weckalarmen läßt sich ja sagen, wie viele höchstens in einem Zyklus auftreten könnten (notfalls alle, die programmiert wurden und sooft, wie es der durch vorige Alarme verlängerten Zykluszeit entspricht.) und die Zeit erhöht eben die obere Schranke.
Rainer Hönle schrieb:
Interrupts, die mit beliebiger Frequenz von einer externen Quelle generiert werden können und dann mit höherer Priorität als OB1 bearbeitet werden sollen, hebeln eben die Echtzeitfähigkeit des OB1 aus.
Wenn zuviele Interrupts in schneller Folge auftreten, würde eben die auch die Lichtschranke aus meinem Beispiel überfahren, wenn sie an einem normalen Eingang hängt.
...verlängert sich entsprechend die Zykluszeit. Eine reine Addition der Ausführungszeiten des OB 1 und der aufgerufene Bausteine liefert somit zu kurze "Maximalzeiten".
Das ist schon klar. Aber über 90 % der Programme, die ich sehe, benutzen keine Interrupts von externen Quellen ("externe Quellen" ist auch nicht die letztgültige Definition. Ich will sagen: Im Gegensatz zu Interrupts, die von Timern generierte werden oder solchen, die von Spezialhardware, z.B zur Positionierung erzeugt werden. Dabei ist ja wieder durch den Timer oder durch den Positioniervorgang eine Beschränkung der Interrupts pro Zeit gegeben).
Wer halt einen Alarmeingang nutzt, der einen Alarm-OB hoher Priorität aufruft, gefährdet eben die Echtzeitfähigkeit. Könnte ja passieren, daß ein Wackelkontakt ganze Salven von Interrupts liefert...
So etwas kann man aber auch auf jedem anderen echtzeitfähigen System erreichen.
 
Zurück
Oben