TP-Zeitmessung
Von: , Frage gestellt am So, 3. Okt 1999
Hi
Ich suche für ein TP-prog. eine moeglichkeit das program für 0.1 ms zu stoppen.
soll genau so gehen wie delay (x:word) nur eben für 0.1 ms.
danke
laurent
9 Antworten zu dieser Frage
-
Antwort von nach 3 Stunden hilfreich
Re: TP-Zeitmessung
Hallo!
So kleine Wartezeiten sind mit "Delay" definitiv nicht mehr realisierbar (und über Abfragen der Hardware-Uhr via "GetTime" schon gar nicht). Als einzige Möglichkeit sehe ich die, den Prozessor einfach eine Schleife mit irgendeinem Dummy-Inhalt abarbeiten zu lassen. Das ist sogar recht einfach zu machen. Was allerdings ziemlich haarig ist, ist die Schleife so zu kalibrieren, daß der Prozessot zu ihrer Abarbeitung gerade 0.1 ms (oder eine andere gewünschte Zeit) benötigt.
Mich würde auch mal interessieren, zu welchem Zweck Du eine Verzögerung von 0.1 ms benötigst. Vielleicht gibt es ja für Dein konkretes Problem noch eine andere, einfachere Lösung.
Bye
Martin [Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
-
Antwort von nach 6 Stunden hilfreich
Re^2: TP-Zeitmessung
Hi Was allerdings ziemlich haarig ist, ist die
Schleife so zu kalibrieren, daß der
Prozessot zu ihrer Abarbeitung gerade 0.1
ms (oder eine andere gewünschte Zeit)
benötigt.
das ist aber gerade das prob. !
Mich würde auch mal interessieren, zu
welchem Zweck Du eine Verzögerung von 0.1
ms benötigst.
mehrere PC's sollen gleichzeitig über ihre LPT-port's verschiedene Schrittmotoren steuern und dabei über serielle verbindungen daten austauschen.
Im prinzip gehts nur laufen die motoren zur zeit extrem langsam.
es muss also in etwa der gleiche delay auf allen machinen eingehalten werden.
eine dummy-schleife die auf einem P II gleichlang läuft wie auf einem 486 gibt es meines wissens nicht.
da das prog. auf dem PII auch noch im windows läuft glaubt ich auch nicht
an eine automatische Kalibrierung.
Aber ich hab mal ein TP-prog. gesehen das die echte verzögerung von delay (1)
gemessen hat (in ms, mit 5 stellen hinterm komma).
Es muss also irgendwie gehen.
kann man das nicht im assambler machen ?
gibt es wirklich keine "gettime" mit ms-angabe (würde zur not auch gehen) ?
danke
laurent
-
Antwort von nach 16 Stunden hilfreich
Re^3: TP-Zeitmessung
Hallo! mehrere PC's sollen gleichzeitig über
ihre LPT-port's verschiedene
Schrittmotoren steuern und dabei über
serielle verbindungen daten austauschen.
Im prinzip gehts nur laufen die motoren
zur zeit extrem langsam.
Oha! Der letzte Satz macht mich sehr nachdenklich. Hast Du mal rechnerisch abgeschätzt, wie schnell Du die Motoren mit diesem System kriegen kannst? Mach Dir bitte folgendes klar: Wenn Dein jetziger Code beispielsweise Delay(200)-Aufrufe in den Motor-Steuerungsschleifen enthält (Verzögerung um 200 ms) und die Motoren damit zwar wie gewünscht laufen, nur sehr langsam, dann kannst Du nie und nimmer erwarten, daß sie eben brav 2000 mal so schnell laufen, wenn Du das "Delay(200)" durch ein (hypothetisches) "Delay(0.1)" ersetzt! Wenn ich mal annehme, daß die PCs jeweils eine Datenmenge in der Größenordnung von 10 Bytes untereinander austauschen, bevor an irgendeinen Motor ein Impuls gesendet wird, dann begrenzt die Zeit, die dieser Datenaustausch benötigt, die Motorgeschwindigkeit. Wenn diese Zeit z. B. 3 ms beträgt, dann machen zusätzliche Verzögerungen von 0.1 ms wenig Sinn. Bitte verschaff Dir mal in Deinem eigenen Interesse über die ungefähren theoretischen Grenzen Deines Systems Klarheit. Sie könnten viel niedriger liegen, als Du es für möglich hälst. es muss also in etwa der gleiche delay
auf allen machinen eingehalten werden.
eine dummy-schleife die auf einem P II
gleichlang läuft wie auf einem 486 gibt
es meines wissens nicht.
Doch, zwei Schleifen, die auf ganz verschiedenen Rechnern etwa(!!!) gleich lange verzögern, sind prinzipiell realisierbar. Die Durchlaufzahl der Schleifen müßte beim Programmstart durch mehrmalige, auf der Hardware-Zeit basierenden Testläufe so bestimmt werden, daß die gewünschte Abarbeitungszeit herauskommt. Dabei wird die Schleife natürlich nicht einmal, sondern z. B. 100000 mal durchlaufen, damit sich Zeiten ergeben, die man stoppen kann (z. B. 1 s). Aber wie gesagt: Das so zu programmieren, daß es hinterher auch funktioniert ;-), ist alles andere als easy. da das prog. auf dem PII auch noch im
windows läuft glaubt ich auch nicht
an eine automatische Kalibrierung.
Das Programm müßte die Verzögerungsschleife z. B. direkt nach dem Start automatisch kalibrieren (übrigens passiert genau das auch in der Unit CRT mit ihrer "Delay"-Prozedur!). Ob das Problem unter Windows allerdings überhaupt noch lösbar ist, wage ich zu bezweifeln. Aber ich hab mal ein TP-prog. gesehen das
die echte verzögerung von delay (1)
gemessen hat (in ms, mit 5 stellen
hinterm komma).
Es muss also irgendwie gehen.
Geht schon, aber mit einem Trick, der Dir bei Deinem Problem nicht weiterhilft. Wenn Du in einer von 0 bis 9999 laufenden Schleife 10000 mal Delay(1) aufrufst, dann dauert das einige Sekunden, die Du bequem über die Harware-Uhr stoppen kannst. Diese Zeit brauchst Du dann nur noch durch 10000 zu teilen und hast Dein (meiner Meinung nach mehr als fragwürdiges)
Ergebnis. kann man das nicht im assambler machen ?
Das Problem ist nicht die eigentliche Schleife, sondern deren Kalibrierung. Deren Programmierung wäre mit Assembler nur noch schwieriger und würde keine echten Vorteile bringen. gibt es wirklich keine "gettime" mit
ms-angabe (würde zur not auch gehen) ?
Nein, GetTime fragt die Hardware-Uhr ab, und die hat eine Auflösung von 55 ms (kein Witz, es sind wirklich 55 ms!).
Wenn ich mehrere (>=2) Schrittmotoren anzusteuern hätte, die schneller als "ganz langsam" und dazu synchronisiert laufen sollten, würde ich immer in Extra-Hardware in Form einer Ansteuerkarte investieren, und die Chose zentral von *einem* PC aus managen.
Entschuldige bitte, wenn sich das alles so anhört, als wollte ich Dir Dein Projekt kaputtreden. Darum geht es mir natürlich nicht. Ich möchte aber, daß Du mal meine Bedenken daraufhin abcheckst, wie weit sie für Dich relevant sind.
Gruß
Martin
-
Antwort von nach einem Tag hilfreich
Re^4: TP-Zeitmessung
Hallo! Oha! Der letzte Satz macht mich sehr
nachdenklich. Hast Du mal rechnerisch
abgeschätzt, wie schnell Du die Motoren
mit diesem System kriegen kannst ?
(...) Wenn ich mal annehme, daß die
PCs jeweils eine Datenmenge in der
Größenordnung von 10 Bytes untereinander
austauschen, bevor an irgendeinen Motor
ein Impuls gesendet wird, dann begrenzt
die Zeit, die dieser Datenaustausch
benötigt, die Motorgeschwindigkeit.
Ich hab mich schlecht ausgedrückt:
Die Pc's kriegen in jedem datenpacket (ca. 16 bytes, 56 kbps) anweisungen für etwa
1 sek. laufzeit der motoren. die
datenkommunikation ist also nicht (mehr) an die drehzahl der motoren gekoppelt.
Das nicht auch nicht das grosse problem.
nur sollen die PC's die bewegung abbrechen
wenn in bestimmtes byte (255) "ankommt".
das byte ist sozusagen das notaus.
zurzeit läuft das system einfach bis zur naechsten datensatzprüfung weiter. diese prüfung wird nur ausgeführt von den PC's wenn keine befehle mehr da sind und besteht aus den auslesen des datensatzes aus einem zwischenbuffer und dem bestimmen der motorbewegung für die neachste sek.
Wenn das klappt wollt ich tatsächlich noch ein sycronisierungsbyte einfügen (z.b. 0). Doch, zwei Schleifen, die auf ganz
verschiedenen Rechnern etwa(!!!) gleich
lange verzögern, sind prinzipiell
realisierbar. Die Durchlaufzahl der
Schleifen müßte beim Programmstart durch
mehrmalige, auf der Hardware-Zeit
basierenden Testläufe so bestimmt werden,
daß die gewünschte Abarbeitungszeit
herauskommt.
Danke, das versuch ich mal. Das Programm müßte die
Verzögerungsschleife z. B. direkt nach
dem Start automatisch kalibrieren
(übrigens passiert genau das auch in der
Unit CRT mit ihrer "Delay"-Prozedur!).
Ob das Problem unter Windows allerdings
überhaupt noch lösbar ist, wage ich zu
bezweifeln.
wuste ich nicht. unter windows versuch ich es jetzt mal mit delphi. Nein, GetTime fragt die Hardware-Uhr ab,
und die hat eine Auflösung von 55 ms
(kein Witz, es sind wirklich 55 ms!).
das ist doch wahnsin, ein c-control hat schon 20 ms auflösung ! Wenn ich mehrere (>=2) Schrittmotoren
anzusteuern hätte, die schneller als
"ganz langsam" und dazu synchronisiert
laufen sollten, würde ich immer in
Extra-Hardware in Form einer
Ansteuerkarte investieren, und die Chose
zentral von *einem* PC aus managen.
die ansteuerung solcher karten soll unter pascal sehr schwierig sein. ich hab's
allerdings noch nie versucht. Entschuldige bitte, wenn sich das alles
so anhört, als wollte ich Dir Dein
Projekt kaputtreden.
Wieso, ich hab doch was gelernt ?
danke laurent
-
Antwort von nach 2 Tagen hilfreich
Re^5: TP-Zeitmessung
Hallo!
Ich glabe du hast da ein grunsätzliches Problem in deinem Konzept. Wenn ich das ganze richtig verstanden habe:
1. steuerst du die Motoren mit dem LPT-Port an !???
2. Das ganze läuft unter Windows ? Was für ne Version?
3. Die Meldungen gehen über ein Netzwerk oder wie ??
Also du hast also, mehr oder weniger ein Multitask-Betriebs-System, das heist im hintergrund laufen diverse Prozesse welche dein Program immer wieder kurz stoppen. Bei langen Zeiträumen (so ab einigen 10 ms) spielt das noch keine Rolle aber bei 0.1 ms hast du schon das Problem das die Zeit immer anders ist, du kannst nur sicher Stellen dass sie nie KLEINER als 0.1 ms ist.
Ich würde das Ganze Problem in 3 Tasks (Threads bein MS) aufteilen.
Der 1. Task steuert den Schritt-Motor der sollte von einem Interrupt gesteuert werden der so im Raster von 0.1ms kommt (dazu kann man einen der Hardware Timer benutzen) dieser Task muss nur die nächste Bit-Kombination an den Schrittmotor ausgeben.
Der 2. Taks übernimmt die Steuerung, also caalle 1 s die neuen Parameter für Task 1 berechnen und übergeben.
Der 3. Taks übernimmt die Abwicklung der Datenübertragung und giebt die Daten normalerweise an Task 2 weiter, ausser wenn irgenwelche Not-Halte ankommen, dann kann er Task 1 sofort stoppen.
mfg P. Götz
-
Antwort von nach 5 Tagen hilfreich
Re^6: TP-Zeitmessung
Hallo!
1. steuerst du die Motoren mit dem
LPT-Port an !???
Ja, 2 motoren pro port, mit transitoren. 2. Das ganze läuft unter Windows ? Was
für ne Version?
nur der Hautp-PC läuft unter windows 98, das ist aber nur ein prob. bei initialisierung von selbstgeschriebenen delay-proceduren. 3. Die Meldungen gehen über ein Netzwerk
oder wie ??
der Hautp-PC ist über ein Nullmoden-kalen mit dem 1. 486 verbunden (steuert 4 motoren). dieser 486 ist über com2 mit einem zweiten 486 verbunden (steuert 2 motoren und liest poti-werte über einen c-control aus)
der hautp-PC steuert das ganze, kann es stoppen, anzeigen ,...
programmiert wird im TP, ich kann nichst anderes gut genug für dieses projekt.
das prob. ist die syncor. der PC => delay von 0.1ms.
mit mulit-treads kenn ich mich nicht aus, genausowenig wie mit irq. timern.
ich brauche "nur" eine delay procedure von 0.1 ms
-
-
-
-
-
-
Antwort von nach 5 Tagen hilfreich
Re: TP-Zeitmessung
Hallo,
es ist im Prinzip möglich eine Delay von 100 uS zu realisieren. Dazu muss du allerdings den im PC eingebauten Hardware Timer abfragen. Dieser Timer ist 16 Bit gross und wird mit 1,193350 MHz getaktet. Normalerweise wird er dazu benutzt um alle 55 mS (1,193350MHz/65536 =18,2Hz = 55mS) einen Interrupt auszulösen der die PC-Uhr dann hochzählt. Diesen Timer kann man allerdings auch auslesen. Auf diese Art dürfte es möglich sein so ein 100 uS Delay in Assembler, alles andere ist nicht schnell genug, zu programmieren (Timerstand auslesen und eine Schleife bis der berechnete Timer-Endwert erreicht worden ist).
Auch die Softwarevariante habe ich schon mit Erfolg ausprobiert (inklusive Kalibrierung). Allerdings, jetzt kommt der grosse Haken. Das ganze funktioniert nur mit puren DOS und ohne sonstige Treiber zuverlässig (auch den Timerinterrupt musste ich ausschalten). Unter W95 sind einfach zuviel Hintergrundprozesse aktiv.
Ich glaube so ganz ohne zusätzliche Hardware wird es nicht funktionieren (zumindest unter W95). Steuerst du die einzelnen Phasen der Schrittmotoren über LPT direkt an ? Wenn Ja benutze doch ein Steuer-IC (z.B. TEA1012). Das IC generiert die Motorphasen und du brauchst nur einen Takt und eine Hand voll Steuersignale. Weiterhin kann man mit einem gemeinsamen Takt alle im System vorhandenen Schrittmotoren ansteuern (Synchronisationsprobleme Ade). So einen Takt kann man auch über den Speaker Output programmieren. Das mit dem Not-Aus über Softwaresteuerung halte ich für keine gute Idee (an so einer Maschine mag ich nicht arbeiten wollen). Fertige Schrittmotorsteuerkarten habe ich ab 150,-DM bei Conrad (S.72) gesehen. Ich hoffe ich habe die ein wenig weitergeholfen.
Gruß
Pit [Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
-
Antwort von nach 7 Tagen hilfreich
Re^2: TP-Zeitmessung
Hallo,
es ist im Prinzip möglich eine Delay von
100 uS zu realisieren. Dazu muss du
allerdings den im PC eingebauten Hardware
Timer abfragen.
Ja aber wie ?
ich programmiere noch nicht so lange dass alle hardware-ports kenne. Dieser Timer ist 16 Bit
gross und wird mit 1,193350 MHz getaktet.
Normalerweise wird er dazu benutzt um
alle 55 mS (1,193350MHz/65536 =18,2Hz =
55mS) einen Interrupt auszulösen der die
PC-Uhr dann hochzählt. Diesen Timer kann
man allerdings auch auslesen.
Wie heisst die auslese-variable (oder was auch immer es ist) (Timerstand auslesen und eine Schleife
bis der berechnete Timer-Endwert erreicht
worden ist).
Kein problem, aber was ist mit dem windows ?
der blockiert mir unter TP seit neustem sorgar die com-port's.
danke
laurent
-
Antwort von nach 9 Tagen hilfreich
Re^3: TP-Zeitmessung
Hallo, allerdings den im PC eingebauten Hardware
Timer abfragen.
Ja aber wie ?
Ich schick die mal eine Beispielsource per Mail ich programmiere noch nicht so lange dass
alle hardware-ports kenne.
Auch da schick ich dir ein File mit Wie heisst die auslese-variable (oder was
auch immer es ist)
Ist keine Variable muss man alles von Hand machen
Gruß
Pit
-
-