Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi Auf Timer verlassen? (https://www.delphipraxis.net/150227-auf-timer-verlassen.html)

hathor 11. Apr 2010 05:34

Re: Auf Timer verlassen?
 
Guckst Du hier:

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

alzaimar 11. Apr 2010 07:11

Re: Auf Timer verlassen?
 
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 11. Apr 2010 08:00

Re: Auf Timer verlassen?
 
Außerdem ist der Timer (TTimer) Nachrichtengesteuert (Windows-Messages siehe MSDN-Library durchsuchenWM_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 11. Apr 2010 11:27

Re: Auf Timer verlassen?
 
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 11. Apr 2010 11:55

Re: Auf Timer verlassen?
 
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 11. Apr 2010 12:07

Re: Auf Timer verlassen?
 
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 11. Apr 2010 12:16

Re: Auf Timer verlassen?
 
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 11. Apr 2010 22:01

Re: Auf Timer verlassen?
 
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 12. Apr 2010 09:01

Re: Auf Timer verlassen?
 
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 12. Apr 2010 09:50

Re: Auf Timer verlassen?
 
Gehen diese System nicht in Richtung Soft-SPS?


Alle Zeitangaben in WEZ +1. Es ist jetzt 11:06 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz