Zitat von Der schöne Günther:

Wie gesagt, Windows ist primär ein Client-System mit einer GUI für den Endbenutzer für den Monitor, weniger ein RT-OS.

Dass Windows in seinem Thread-Scheduling die Priorität für Threads und Prozesse herunterfährt die "nicht sichtbar" sind ist bekannt und gewollt. Genauer erklärt und wie sich das steuern lässt findet sich hier:

https://docs.microsoft.com/en-us/win...riority-boosts

Ok. Das schaue ich mir mal genauer an. Grundsätzlich gibt es ja Möglichkeiten. Es können ja z.B. auch Audio oder Videodaten im Hintergrund aufgezeichnet werden, was zeitkritischer ist. Allerdings muss ich halt Aufwand/Nutzen abwägen. Und wie gesagt: Mit Reaktion < 100ms ist es kein Problem (was derzeit gegeben ist). Ich muss mir das mal auf dem "schwachbrüstigeren" Zielsystem anschauen. Normalerweise läuft die Anwendung auch im Vordergrund. Allerdings haben wir Kunden die gerne auch mal die Rechner Dinge missbrauchen, was sie eigentlich nicht dürfen...

Was Du probieren könntest wäre einen Service zu verwenden. Dann ist zumindest der Fall weg das sich der Zeitabstand signifikant ändert wenn der Nutzer am System spielt. Die Aufzeichnung kann auch dann weiter gehen wenn die Anwendung gekillt wird.
Von CPU prioritäten für die Services habe ich aber keine Ahnung. Mein Service macht nur ca alle zwei Stunden mal was. Genau muss das nicht sein.

Was mich wundert ist, dass unter normalen Umständen (Fenster nicht minimiert) die Schwankung immer maximal bei +/-1 ms ist. Wäre die Auflösung von "Now" (GetLocalTime) bei 16ms - wird zumindest überall behauptet - dann müsste ich doch immer ein Vielfaches von 16ms als Schwankung erhalten. Tatsächlich bewegt sich das aber immer im Bereich +/-1 ms.

Wo habe ich da den Denkfehler???

Ich habe das ganze auch eben mal mit TStopwatch gegengeprüft. Der Fehler ist bei normaler Ausführung nie größer als 1ms...

Ich vermute das der Thread in Priorität eine Stufe herb gesetzt wird sobald die Anwendung nicht den Focus hat.

Dass die Anwendung die im Vordergrund ist hat immer die höhere Priorität.

Kannst das ausprobieren mit zwei gleichen Anwendungen und eine davon im Vordergrund. Dann sollte diese schneller sein.

Früher konnte ich einen Download beschleunigen, wenn ich die Anwendung mit dem Download im Vordergrund gehalten habe. Es ist aber nur ein minimaler Unterschied.

Zitat von Edelfix:

Ich vermute das der Thread in Priorität eine Stufe herb gesetzt wird sobald die Anwendung nicht den Focus hat.

Das die Anwendung die im Vordergrund ist hat immer die höhere Priorität.

Kannst das ausprobieren mit zwei gleichen Anwendungen und eine davon im Vordergund. Dann sollte diese schneller sein.

Das mit dem Fokus war auch mein erster Gedanke. Allerdings merke ich erst einen Verlangsamung wenn ich die Anwendung minimiere. Lass ich das Fenster offen und lege eine andere Anwendung in den Vordergrund bleibt die Genauigkeit...

Also: Habe mal Now etwas näher analysiert. Die Auflösung ist - meiner Meinung nach - 1 ms:

zusammenfalten · markieren

Delphi-Quellcode:

var
  OldTime: TDateTime = 0.0;
  OldTick: UInt64;
  Times: TArray<TDateTime>;
begin
  try
    OldTick := GetTickCount64;
    repeat
      if Now <> OldTime then
      begin
        Times := Times + [Now];
        OldTime := Now;
      end;
    until GetTickCount64 > OldTick + 20;

    WriteLn;

    for var I := Low(Times) to High(Times) do
      WriteLn(I:5, ' = ', FormatDateTime('hh:nn:ss.zzz', Times[I]));

    ReadLn;
  except
    on E: Exception do
      WriteLn(E.ClassName, ': ', E.Message);
  end;
end.

Als Ergebnis erhalte ich z.B.:

markieren

Code:

    0 = 12:14:49.512
    1 = 12:14:49.513
    2 = 12:14:49.514
    3 = 12:14:49.515
    4 = 12:14:49.516
    5 = 12:14:49.517
    6 = 12:14:49.518
    7 = 12:14:49.519
    8 = 12:14:49.520
    9 = 12:14:49.521
   10 = 12:14:49.522
   11 = 12:14:49.523
   12 = 12:14:49.524
   13 = 12:14:49.525
   14 = 12:14:49.526
   15 = 12:14:49.527
   16 = 12:14:49.528
   17 = 12:14:49.529
   18 = 12:14:49.530
   19 = 12:14:49.531
   20 = 12:14:49.532
   21 = 12:14:49.533
   22 = 12:14:49.534
   23 = 12:14:49.535
   24 = 12:14:49.536
   25 = 12:14:49.537

Warum wird überall (z.B. SO) behauptet die Auflösung sei bestenfalls 16ms, eher 20ms???

Ein "Hintergrund"-Thread läuft doch über den Dispatcher des Main-Threads soweit ich weiß, zumindest unter Windows.

Ok. hab eben mal ein paar anderen Maschinen getestet. Auflösung auf älteren Rechner 16ms auf aktuellen 1ms...

Und wie kommen die Daten von der SPS?

ComPort und TCP-Stack haben ja einen Cache, womit es garnicht wichtig wäre, dass es schnell und genau getimet gelesen wird ... so lange man nur insgesamt schneller liest, als der Cache voll läuft.