Timing-Event im 10ms-Bereich

[MaxDelphi]

Hallo Leute,

nochmals Danke für eure Hilfe. Oftmals sind es doch die Anregungen der anderen die einen wieder frei denken lassen, so daß einem neue Suchbegriffe einfallen und einen zum Ergebnis führen. Bei mir waren das "time slice" -> "win32priorityseparation" -> "quantum" -> "timeBeginPeriod" -> und schon war ich wieder bei euch gelandet und zwar:

Delphi für Win32
Schneller Timer gesucht
Im 11. Beitrag hat Gandalfus den Link zu einem guten Tutorial gepostet, womit mir gelungen ist was ich gesucht habe -> Timing-Events <= 10ms ohne Prozessorlast. Wobei die Genauigkeit der 10ms nicht so bedeutend sind, sondern ich wollte auf ca. 100Hz kommen.

Ich hänge ein kleines Programm an, das dem besagten Tutorial entnommen ist und von mir modifiziert wurde. Es enthält wieder Now und nun glaube ich es auch: Now ist nicht besonders exakt!! Aber wenn man die Events eine Weile auflaufen läßt und die verstrichen ms von Now durch die Anzahl der Durchläufe teilt kommt man wieder auf ca. 10ms.

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ExtCtrls, mmsystem, StdCtrls; //!!!!  mmsystem einbinden (für timegettime)
type
   TMsgContainer   = class
   public
      Msg   : string;
   end;

  TThreadTimer = class(TThread)
  private
    TheMsg: TMsgContainer;
    Zeit: int64;
    t0   : TDateTime;
    Cnt   : Int64;
  published
    procedure Execute; override;
    procedure OnTimer;
    constructor CreateMitCanvas(AMsg: TMsgContainer); virtual;
  end;

  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    Memo1: TMemo;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    ThreadTimer: TThreadTimer;
    Timerid: integer;
    MyMsg   : TMsgContainer;
  end;

var
  Form1: TForm1;

implementation
{$R *.dfm}

//Dem constructor wird eine zeichenfläche übergeben,
//damit klar ist wohin gezeichnet werden soll
constructor TThreadTimer.CreateMitCanvas(AMsg: TMsgContainer);
begin
  inherited create(true);
  TheMsg := AMsg;
  Zeit := Timegettime ;          //Die Startzeit wird ermittelt
  t0   := Now;
  Cnt   := 0;
  resume;
end;

procedure TThreadTimer.Execute;
begin
  while not Terminated do
  begin
    sleep(1);
    OnTimer;
  end;
end;

procedure TThreadTimer.OnTimer;
Var
   NewTime, Delay   : int64;
   ElapsedMS   : TDateTime;
begin
   NewTime   := timegettime;
   Delay   := NewTime-Zeit;
   ElapsedMS   := (Now-t0)*86400000;
  if NewTime-Zeit>=9 then //Jeweil nach einer Sekunde
  begin
   Inc(Cnt);
    TheMsg.Msg   := TheMsg.Msg   + Format('%.3d %8.3fms %d',[Cnt,ElapsedMS,delay]) + #13#10;
    zeit:= NewTime; //neue Start Zeit ermitteln
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
   MyMsg   := TMsgContainer.Create;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  MyMsg.Free;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
   MyMsg.Msg   := '';
  ThreadTimer := TThreadTimer.CreateMitCanvas(MyMsg);
  Button1.Enabled   := False;
  Button2.Enabled   := True;
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
   ThreadTimer.DoTerminate;
  ThreadTimer.free; //Timer freigeben
  memo1.Text   := MyMsg.Msg;
  Button2.Enabled   := False;
  Button1.Enabled   := True;
end;

end.

Damit sehe ich das Problem als gelöst an.
Nochmals vielen Dank für eure Mühe.

[Luckie]

Mal was anderes. Wozu brauchst du so eine geringe Auflösung? Eventuell gibt es da noch eine bessere Lösung. allgemein ist es immer schelcht einen Zustand immer wieder abzufragen. Besser ist es sich über einen Zustand mittels eines Ereignisses benachrichten zu lassen. Nicht umsonst wurde ja auch die Türklingel erfunden.

[MaxDelphi]

Hallo Luckie,

wenn du noch eine ereignisgesteuerte Lösung hast dann her damit, schau ich mir gerne an. Allerdings müssen die Ereignisse <= 10 ms ankommen und die CPU darf nicht ausgelastet werden; dieses Verhalten hatte ich erst im letzten Beispiel gesehen.

Des weiteren soll mir dieser Timer bei einer messtechnischen Anwendung helfen. Ich bekomme Daten aus verschiedenen Quellen geliefert, die sich hardwareseitig nicht synchronisieren lassen. Einerseits von Motorreglern (grobe Werte aber hohe Taktrate) andererseits Messdaten von einem Messverstärker (genaue Werte, langsame Taktrate). Die Werte lassen ich in ein gemeinsames Datenfeld laufen und hole sie mir dann "Quasi-Synchron" mit dem Timer ab. Und hier möchte ich auf ca. 100Hz kommen, damit ich dem Motorregler auch noch sagen kann wo es langgeht.

Die Idee Signale direkt vom Messverstärker in den Motorregler zu packen hatte ich auch schon allerdings ist der dort verbaute AD-Wandler zu schlecht. Es gibt auch noch weitere Gründe dagegen, so daß ich auf ein Softwaregeführte Variante zurückgreifen muß.

Ansonsten wünsche ich Euch allen noch einen schönen geruhsamen Abend.

[himitsu]

Da wäre hier ein Microcontroler angebrachter, welcher die Ein- und Ausgangswerte mit passend seuern kann und diesen könnte man dann auch vom PC aus ansteuern ... zwar nicht alle 10ms (obwohl dieses auch möglich wäre).

Ein µC könnte 100 Hz wesendlich leichter einhalten
und dazu kommt noch, daß durch andere Umstände der PC auch mal "blockiert"/ausgebremmst sein kann und dann selber die 100 Hz garnicht mehr hinbekommt.

Falls die Messwerte dennoch für 100 Hz im PC auftauchen sollte, könnte der µC diese Werte auch mal zwischenspeichern und ich (un)regelmäßigen Abständen vom PC abgefragt bekommen.

[hathor]

Mit QPF-QPC sind auch 0,1 msec möglich:

[himitsu]

Zitat von hathor:

Mit QPF-QPC sind auch 0,1 msec möglich:

Allerdings bei nahezu 100% CPU-Last, was man aber nicht wollte

(ok, bei mir insgesammt nur knapp 50%, da 2 CPUs)

[dmdjt]

Hab zu dem Timerproblem eine kleine Frage:

Kann man eigentlich nicht irgendewelche Dinge verwenden, die so oder so mit hoher Taktrate laufen und echt exakt sein müssen? Also zb das man Irgendwas von der Soundkarte einen Event auslösen läßt?

Ich weiß nur, dass es bei Softwaresynthesyzer ja auch irgendwie gehen muss wenn die ein live ein Geräusch produzieren können.

[himitsu]

Zitat von dmdjt:

und echt exakt sein müssen?

ist einfach nicht möglich, da immer irgendwas dazwischenfunken kann.

man kann zwar einem Prozess eine sehr hohe Priorität verpassen > Stichwort: critical time <
aber dann kann immernoch ein interrupt oder irgendelche Hardware dazwischenfunken
und zusätzlich ist der restliche PC nicht mehr bediehnbar.

Zitat von dmdjt:

Ich weiß nur, dass es bei Softwaresynthesyzer ja auch irgendwie gehen muss wenn die ein live ein Geräusch produzieren können.

die produzieren mit Sicherheit kleine Soundhäppchen und schicken diese an die Soundkarte.
es wird bestimmt nicht der Soundausgang direkt angesteuert > das würde ja zu Knacken anfangen, sobald auch nur eine kurze Pause auftritt.

[Luckie]

Zitat von MaxDelphi:

wenn du noch eine ereignisgesteuerte Lösung hast dann her damit

Zu was denn? Du hast uns ja dein Problem nicht geschildert, sondern nur Lösungen genannt, die dich nicht befriedeigen.

@Reinhard Kern: Unter Windows NT hat der Timer eine minaml Auflösung von 15 ms. das hat mit der Geschwindigkeit der CPU nichts zu tun. Hinzukommt, dass die Timernachrichten im System eine sehr geringe Priorität haben, also schon mal etwas länger in der nachrichtenschlange stehen können. Hinzukommt, dass jeder Prozess eine Zeitscheibe von 20 ms zur CPU Nutzung zu gewiesen bekommt. Prozesse mit einer höheren Priorität kommen entsprechend öfters dran. Über den genauen Scheduling Algorithmus macht Mictrosoft keine genauen Angabewn, damit die Entwickler in ihren Anwendungen keine schmutzigen Tricks benutzen und dann nmit der nächsten Windows Version auf die Nase fallen, da es Microsoft sich vorbehält den Scheduling Algorithmus zu ändern, um die Systemperformance beständig zu verbessern.