Wegmessung in Thread -> v und a berechnen Theoriefrage

[BAMatze]

Hallo und guten Tag an alle DP´ler,

Mal eine rein theoretische Frage zu der Berechnung von Geschwindigkeit und Beschleunigung eines sich bewegenden Objektes mittels Thread. Wobei eigentlich die Genauigkeit einer solchen Berechnung interessant für mich ist, da ich ja schon oft gelesen hab, dass Windows ja keine "Echtzeit-BS" ist. Die restliche Theorie betreffend Geschwindigkeit ist Ableitung des Weges nach der Zeit, Beschleunigung ist Ableitung der Geschwindigkeit nach der Zeit oder die zweite Ableitung des Weges nach der Zeit, ist mir schon klar.

Also ich verwende folgende Execute-Fkt in meinem Thread:

Delphi-Quellcode:

procedure TControlCardControlThread.Execute;
var c, iIndex: integer;
begin
  for iIndex := 1 to 5 do (Form3.findcomponent('CheckBox' + inttostr(iIndex+8)) as TCheckBox).Checked:= fabDigChannelSignals[iIndex];
  repeat
  c := GetTickCount;
  // hier soll nun eine Wegmessung erfolgen und diese soll mit der vorhergegangenen Messung des Threaddurchlaufes verglichen werden und über das Intervall in Geschwindigkeit und Beschleunigung überführt werden.
  bUpdateDataForm1 := ComportSearch(FsLComport);
  Synchronize(UpdateForms);
  c := {interval}50 - (GetTickCount - c);
  if c > 0 then Sleep(c);
until Terminated;
if assigned(FsLComport) then FsLComport.Free;
end;

Meine Frage ist nun: Ich habe das Intevall des Threads ja auf 50ms festgesetzt. Wie genau werden diese 50ms denn eingehalten? Es ist ja bekannt, dass die Threads immer einen zuteilungsfähigen Status und einen ruhenden Status haben. Wird wirklich nach 50ms die repeat-Schleife des Threads neu gestartet, so dass ich exakt sagen kann, v = ((Differenz der Wegmessung)/ 50ms) oder ist das eher nach dem Motto 50ms +/- Tolleranz (mir ist schon bewusst, dass ein Teil meines Intervalls durch das Abarbeiten meiner Routinen im Thread verbraucht werden)?

Hoffe jemand kann mir da eine genaue Auskunft geben.
Vielen Dank
BAMatze

[sirius]

1. "Form3.findcomponent(" -- Ganz schlecht. Du greifst auf die VCL zu.
2. Die 50ms werden sehr ungenau getroffen. Was hindert dich daran in unbestimmten Zeitintervallen zu fragen und dies über die Uhr o.ä. zu regeln.

[BAMatze]

Zitat:

Zitat von sirius

1. "Form3.findcomponent(" -- Ganz schlecht. Du greifst auf die VCL zu.

Ah ok werde ich gleich ändern, bis jetzt hat sich da zwar kein Fehler ergeben, aber ist natürlich besser dies zu ändern. :thumb:

Zitat:

Zitat von sirius

2. Die 50ms werden sehr ungenau getroffen. Was hindert dich daran in unbestimmten Zeitintervallen zu fragen und dies über die Uhr o.ä. zu regeln.

Eigentlich hielt mich bis ebend nur ab, das ich selber noch nicht auf die Idee kam, aber hast natürlich Recht, könnte dort ja sehr genau die Zeiten abfragen des Systems, wenn ich in einem Schleifendurchlauf bin und diese dann auch in Realtion zu der vorherigen Messung setzen, was mich dann zu einer relativ genauen Bestimmung von v und a führen sollte (wenn ich dich jetzt richtig verstanden hab).

BAMatze

[Uwe Raabe]

Generell ist der Aufruf von Synchronize im Thread möglichst zu vermeiden. Da hier eine Synchronisation mit dem Hauptthread erfolgt, ist das Zeitverhalten absolut nicht vorhersehbar und der Vorteil des Threads ist schnell dahin. Das Gleiche könntest du auch mit einem einfachen Timer erreichen.

Wenn im Synchronize lediglich Anzeigewerte aktualisiert werden, ist es besser, diese in einem OnIdle- oder OnTimer-Event zu aktualisieren, wobei eventuell der Zugriff auf die aktuellen Werte threadsicher gestaltet werden muß.TMultiReadExclusiveWriteSynchronizer

Die Zeitdifferenz kann man übrigens sehr gut mit dieser Stoppuhr messen.

[BAMatze]

Also der Thread hat in der Synchronize-Anweisung einige Absicherungen (Überwachung von Anschlagssensoren) die die Bewegung absichern sollten. Vieleicht hab ich das am Anfang, wo ich noch Timer verwendet hab ja nicht richtig gemacht, aber erst mit dem Thread ist es mir gelungen, diese Überwachung über die gesamte Zeit sicherzustellen. Bei den Timern kam ab und zu aufgrund der Arbeiten im Hauptthread deutliche Verzögerungen zustande, die ich nicht unter Kontrolle bekommen hab.

[Tryer]

Um de Berechnungen durchführen zu können gehört also zu jedem Wegpunkt auch ein Zeitstempel.
-> Zu jedem Wegpunkt GetTickCount speichern (vorher ein Sleep(0) damit die Anweisungen "Position auslesen" und GetTickCount mgl. unterbrechungsfrei ausgeführt werden, bzw. vorher und nachher GetTickCount auslesen und den Mittelwert zum Wegpunkt zuordnen).
Alternativ z.B. QueryPerformanceCounter, das ist deutlich genauer (nur leider auch langsamer) als GetTickCount.

Dann kann die Berechnung unabhängig von den 50ms "Updateintervall" erfolgen.

Grüsse, Dirk

[BAMatze]

Ah ok werde ich beides mal auprobieren, sowohl die Zeitnahme aus dem System und auch deinen Vorschlag @Dirk.