Auf Timer verlassen?

[DarkItachi]

Hi,

Kann man sich auf einen Timer verlassen?
Also ich meine, ich muss eine reelle Sekunde warten...
Macht der Timer die 1000ms wahrheitsgetreu?

Oder kann der Wert durch die Leistung des PC's variieren?

Naja, schon mal dickes Danke wie immer!

MfG

[SirThornberry]

Du kannst dich auf den Timer genauso wenig wie auf alles andere verlassen wenn du Millisekunden genau arbeiten willst. Windows ist ein Multitasking Betriebssystem und somit kann es sein das in der Millisekunde dein Programm gar keine Rechenzeit bekommt und somit den Moment verpasst.

[fatalerror]

Ein normaler Timer wird bei Windows nicht prioritär behandelt - somit darf sich ein Programm nicht auf das genaue Eintreffen des Ereignisses verlassen. Es sollte aber Alternativen zum normalen Timer geben. Suche mal nach Multimediatimer.zb. hier Wichtig ist aber zu wissen, das Windows nicht ein Echtzeitbetriebssystem ist.

[Lumpiluk]

Zitat:

Zitat von DarkItachi

Also ich meine, ich muss eine reelle Sekunde warten...

Ich kann mir nicht so ganz vostellen, worauf und wofür...
Vielleicht kann man das anders lösen?

[Christian Seehase]

Moin,

auf den Timer würde ich mich nicht verlassen, zumal Windows kein Echtzeitbetriebssystem ist.
Der Multimedia Timer soll präziser sein, aber Abweichungen können auch bei diesem Auftreten.

[XXcD]

Es gibt eine Möglichkeit mit Delphi punktgenaue Timer zu nutzen.

Ich müsste mal nachschauen wie das hieß, das ist eine Software die sich in den Kernel von Windows einklinkt und damit kann man beispielsweise Skriptsprache, C++ und Delphi nutzen.

[DarkItachi]

Brauchen tue ich das nicht. Ich wollte einfach nur mal wissen, ob man es kann.
Aber hier erhält man ja genug Informationen!

Ich brauche nur ein Timer, der etwa jede Sekunde die Label Caption um 1 verringert.

Aber jetzt weiß ich ja Bescheid!
Thx

€d1t: Noch etwas, was ich gerne wissen möchte.. Erstellt ein Timer einen Thread?

[Delphi-Laie]

Zitat:

Zitat von DarkItachi

€d1t: Noch etwas, was ich gerne wissen möchte.. Erstellt ein Timer einen Thread?

Nein, er löst nur intervallweise eine Aktion (Prozedur) aus. Diese sollte möglichst abgearbeitet sein, wenn sie - bzw. eine neue Version davon - aufgerufen wird, ansonsten kommt es natürlich zu zeitlichen Überschneidungen. Oder es wird die Neuauslösung blockiert, genau weiß ich es nicht.

An XXcD: Das würde mich auch interessieren.

[DarkItachi]

Aber der Timer muss das Intervall ja auch zählen.
Dafür müsste doch ein Thread erstellt werden..
Sonst würde das Programm ja dauernd flackern oder so..

Oder sehe ich das falsch?

[Valle]

Der Timer benutzt eine WinAPI Funktion, die Windows das zählen überläst. Windows benachrichtigt dein Programm (den Timer) dann mit Hilfe einer Window Message über das Auslösen der Timer-Funktion. Somit ist der Timer nicht-blockend. :-)

Liebe Grüße,
Valle

[hathor]

Guckst Du hier:

http://www.delphi-forum.de/viewtopic...ighlight=sleep
http://www.delphi-forum.de/download.php?id=7204

[alzaimar]

Zitat:

Zitat von DarkItachi

Ich brauche nur ein Timer, der etwa jede Sekunde die Label Caption um 1 verringert.

Böser Fehler. Merk Dir lieber die Anfangszeit und schreib im OnTimer-Event die Differenz in das Label (bzw. Konstante abzüglich der Differenz, wenn Du rückwärts zählen willst). Ansonsten wird das irgendwann ungenau.

[himitsu]

Außerdem ist der Timer (TTimer) Nachrichtengesteuert (Windows-Messages siehe WM_TIMER).
Heißt, selbst wenn die Message zufällig pünklich verschickt wird, dann landet sie erstmal im Message-Queue und wird erst im TTimer ausgelößt, wenn die Nachrichtenverarbeitung an dieser Nachricht vorbeikommt.

Da zu dann noch das schon genannte Proplem des Multiprozessings.


Egal wie, genaue Verarbeitung kann es nie geben.
Und dieses Problem haben auch Linux und Mac.


Einzige Lösungen wären z.B. Interrupt-gesteuerte Timer oder eine Umstellung auf Single-Prozessverarbeitung.

[fatalerror]

Zitat:

Zitat von himitsu

... Egal wie, genaue Verarbeitung kann es nie geben.
Und dieses Problem haben auch Linux und Mac.

Bei Linux ist es so eine Sache, es gibt kein eigentliches Linux sondern hunderte unterschiedliche Distributionen und unter diesen Linuxdistributionen gibt es auch Echtzeitsysteme zb das Real Time Linux.

[edit]link korrigiert[/edit]

[himitsu]

Zitat:

Zitat von fatalerror

Bei Linux ist es so eine Sache, ...

100%ige Echzeitbehandlung kannst du eigentlich nur bekommen, wenn in dem PC nur ein Prozess läuft und dieser praktisch unterbrechnungsfrei, vorzugsweise Hardwaregesteuert, zeitnah Ereignisse auslösen/ausführen kann oder daß dieses Programm entsprechend schnell die Kontrolle über das System erlangen kann, wenn ein Ereignis ansteht.

Ich denke mal daß kann selbst dieses Linux nicht zu 100%.
Aber im Notfall kann man auch ein Windowsprogramm in einen Zustand versetzen, daß dieses nahezu so läuft, als liefe es in einem Echtzeitsystem, allerdings mit dem Nachteil, daß eventuell das System so belastet wird, daß nichts Anderes mehr reagiert.

Höchste Prozess- und Threadpriorität für einen Prozess.
Wer sowas mal, vorallem auf einem SingleCore, über "längere" Rechenzeit hinweg versucht hat, der weiß was ich meine.

Daß Problem ist esben, daß in eigentlich allen modernen Systemen (mit einigen wenigen Ausnahmen) immer irgendwas parallel läuft, womit die Grundvorausetzung für eine Echtzeitbehandlung doch eigentlich nahezu ausgeschlossen ist.
(unzählige Treiber, Services und Co. sind doch ständig aktiv)

Dank Multiprozessoring könnte man aber ein Programm an einen physischen Kern binden ... wenn man dann noch allen anderen Prozessen verbietet diesen Kern zu nutzen und es auch noch nahezu ausgeschlossen ist, daß die restlichen Resourcen/Harwarekomponenten sich nicht gegenzeitig so stark beeinflussen, so daß die Abarbeitung in dem reservierten Kern zu sehr beeinflußt wird, dann würde das Programm dort wohl nahezu in Echtzeit reagieren können.

[Sir Rufo]

Weiterhin muss noch beachtet werden, dass die Anwendung selber auch die Verarbeitung eines Timer-Events blockieren kann.

Wenn dieses ausgeführt wird, dann wird in dieser Zeit keine Warteschlange abgearbeitet:

Delphi-Quellcode:

procedure TForm1.Unsinn;
begin
  Sleep( 10000 ); // Beispiel für einen Code, der 10 Sekunden für die Verarbeitung benötigt
end;

Somit ist es nicht nur das Betriebssystem sondern auch die Anwendung, die eine Echtzeitverarbeitung verhindert.

Eine wirkliche Echtzeitverarbeitung ist aber auch nur in wenigen Fällen wirklich notwendig (z.B. in der Steuer- und Regeltechnik).

Keinen Anwender interessiert es, ob der Download wirklich und wahrhaftig in 13,865743 Sekunden beendet ist.

[himitsu]

Zitat:

Zitat von Sir Rufo

Eine wirkliche Echtzeitverarbeitung ist aber auch nur in wenigen Fällen wirklich notwendig (z.B. in der Steuer- und Regeltechnik).

Und da wäre es eh besser einen, von der "Benutzersteuerung" unabhängigen Steuerkomputer zu nehmen, welcher sich wirklich nur um die Steuerung kümmert und wo praktisch sonst nichts nebenbei läuft (oder eben ein/mehrere Microcomputer).

[XXcD]

So hat zwar lange gedauert aber ich habs endlich gefunden, wollten ja glaube ich auch noch andere wissen wie das geht.

http://www.kithara.de/en/home.html

Das ist die Realtime Suite und damit lassen sich punktgenau aktionen unter Windows steuern.

[LargoD]

Zitat:

Zitat von XXcD

http://www.kithara.de/en/home.html

Das ist die Realtime Suite und damit lassen sich punktgenau aktionen unter Windows steuern.

Das läuft eher so, dass Windows als eine Task unter dem Echtzeitsystem läuft. Man hat als Programmierer in der Echtzeitapplikation nicht die Windows-Funktionalität zur Verfügung, kann aber über verschiedene Mechanismen mit Windows kommunizieren und hat damit für die nicht zeitkritischen Programmteile (vor Allem GUI) alle Vorteile von Windows.

Außer Kithara gibts da noch u. a.:

TwinCat von Beckhoff
OnTime von Ontime
InTime von Tenasys (setze ich ein)

Gruß
Erich

[divBy0]

Gehen diese System nicht in Richtung Soft-SPS?

[LargoD]

Zitat:

Zitat von divBy0

Gehen diese System nicht in Richtung Soft-SPS?

Soft-SPS ist nur eine Anwendung von vielen, dann kommt der Anwender natürlich mit dem Realtime-Kern nicht in Berührung. Eine andere häufige Anwendung ist ein CNC-Kernel für N Achsen, auch dann sieht der Anwender den Realtime-Kern nicht mehr, es geht aber nicht ohne.
Wenn Du mit Software schnelle Regelungen aufbauen willst, kommst Du um Echtzeit nicht herum.
Gruß
Erich

[himitsu]

Zitat:

Zitat von LargoD

Wenn Du mit Software schnelle Regelungen aufbauen willst, kommst Du um Echtzeit nicht herum.

Solange die minimal nötige Reaktionszeit der Regelung unter der maximalen Reaktionszeit des Systems/PCs liegt, dann geht es auch ohne.

Aber ich würde eh nicht "kritische" Regel-Anwendungen auf einem PC laufen lassen,
dafür ist so ein komplexes System doch zu unberechenbar und kann parktisch zu jeder Zeit abstürzen, hängen oder Dergleichen.

[Sherlock]

Äh, ich glaube nicht, daß es an der Hardware hängt, eher am OS. Im Studium hatten wir zum Beispiel als "echtes" Realtime OS mit LynxOS hantiert. Embeddedsysteme sind am Ende ja auch nur PCs, mit verkleinertem Funktions-/Hardwareumfang.

Sherlock

[LargoD]

Zitat:

Zitat von himitsu

Solange die minimal nötige Reaktionszeit der Regelung unter der maximalen Reaktionszeit des Systems/PCs liegt, dann geht es auch ohne.

Dieser Aussage stimme ich zu, aber:
Ich rede hier von Windows-Systemen. Zeige mir bitte ein Windows-System, bei dem Du die maximale Reaktionszeit unter allen Bedingungen sicher garantieren kannst. (Inclusive beliebige I/O Operationen, An- und Abstöpseln von Geräten und Bluescreen)

Zitat:

Zitat von himitsu

Aber ich würde eh nicht "kritische" Regel-Anwendungen auf einem PC laufen lassen,
dafür ist so ein komplexes System doch zu unberechenbar und kann parktisch zu jeder Zeit abstürzen, hängen oder Dergleichen.

Es ist ja gerade der Trick, die "kritischen" Aufgaben außerhalb von Windows abzuwickeln, selbst wenn Windows abstürzt, läuft die Realtime-Applikation weiter. Das kann ich Dir vorführen.
Wenn Du Dich mal bei aktuellen Automatisierungslösungen umschaust wirst Du sehr viel PC-Technik (auch in der Software) finden.
Aber jeder wie er will (oder wie der Kunde es will).
Gruß
Erich

[himitsu]

Zitat:

Zitat von LargoD

Es ist ja gerade der Trick, die "kritischen" Aufgaben außerhalb von Windows abzuwickeln, selbst wenn Windows abstürzt, läuft die Realtime-Applikation weiter.

OK, wenn dem so ist, dann ginge es natürlich.

Also dieser "Ding" läuft praktisch wie ein eigenes OS und Windows läuft dann quasi wie in einer VM nebenher? (bereinfacht gesprochen)

Zitat:

Zitat von LargoD

Zeige mir bitte ein Windows-System,

Blos nochmal für die anderen "Linux ist immer und überall besser"-Finder ... selbst Linux ist hier standardmäßig und ohne soeine Erweiterung nicht besser dran. :tongue:

[mkinzler]

Es gibt aber wie schon erwähnt Erweiterungen die Linux RT fähig machen

[himitsu]

Zitat:

Zitat von himitsu

ohne soeine Erweiterung

:zwinker:

und wie es aussieht gibt es sowas auch für Windows :angel2:

[mkinzler]

Das habe ich schon gelesen, aber es gibt diese ( 1System) zum Unterschied zu den Lösungen mit Windows ( 2 Systeme parallel)

[LargoD]

Zitat:

Zitat von himitsu

Also dieser "Ding" läuft praktisch wie ein eigenes OS und Windows läuft dann quasi wie in einer VM nebenher? (bereinfacht gesprochen)

Jein.
Ich kann es jetzt im Detail nur für InTime von Tenasys beschreiben.
Bei der Konfiguration des Realtime-Kernels legst Du fest, was vom PC dem Windows weggenommen und dem Kernel zugeteilt wird. Alle Hardware, die nicht dem Kernel zugeteilt wird, wird weiterhin direkt von Windows bedient. Der RT-Kernel dient also nicht als gastgebendes System für eine VM, er kennt einen großen Teil der Hardware garnicht. Er verwaltet die ihm zugeteilte Hardware, verteilt die Rechenzeit und stellt die Kommunikationswege zwischen den Tasks zur Verfügung.
Gruß
Erich