Hi, für ein Projekt (Schrittmotorsteuerung via Parallelport) benötige ich ein fixes Zeitintervall. Das erste Problem ist, das Zeitintervall soll nicht durch andere Anwendungen gestört werden, da bei kleinsten Zeitverzögerungen der Schrittmotor mit dem Steuerprotokoll desynchronisiert, was zu einem zusätzlichen Drehmomentverlust führt, evlt. kann es sogar zum abrupten Stillstand führen, besonders bei höheren Umdrehungszahlen (z.B. 250 - 1000 U/min) Das zweite Problem ist, das Programm soll unter WIN98SE laufen. Ich habe mir folgendes gedacht: ich lasse z.B. den PIT-Baustein des PC ab einem fixen Startwert laufen, hat der Timer zuende gezählt soll über ein Hardware-Interrupt mein Programm aufgerufen werden, welches dann den nächsten Schaltimpuls für den Schrittmotortreiber erzeugt. Besonders wichtig ist hier der Startwert, über ihn kann die Geschwindigkeit des Motors eingestellt werden... Das Programm schaltet also den nächsten Impuls, und schreibt in den PIT erneut einen Startwert, worauf es die Kontrolle an andere Windows-Programme abgibt. Soweit so gut. Die Frage ist jetzt, funktioniert das? Soweit ich weiß hat ein PC mindestens einen PIT, häufig sogar zwei. Falls zwei vorhanden sind: kann ich den sogenannten "Fail-Safe-Timer", also den zweiten PIT, für mein Vorhaben mißbrauchen? D.h. der Fail-Safe-Timer ruft über Hardware-Interrupt mein im Speicher residentes Programm auf, welches den nächsten Impuls an den Parallelport schickt (und vorher kurz auch schaut, ob evtl. ein Abbruch durch den USER erfolgt ist), dann wieder den nächsten Startwert in den PIT schreibt, und mit IRET wieder die Kontrolle an die Windows-Programme abgibt. Wenn das alles so möglich ist, wie führe ich das mit wenig Programmieraufwand durch? Gibts dazu irgendwo Tipps? Kann ruhig "dreckig" sein, es ist ja klar daß ich die Windows-Zeitscheibe umgehen möchte um eine Art REAL-TIME-Programmierung zu bekommen. Habe allerdings bis jetzt noch kein TSR programmiert. Möchte das Ganze mit Delphi bzw. TASM schreiben, möglichst straightforward ohne groß DLLs oder anderen Kram. Soweit ich weiß erlaubt WIN98SE noch Portzugriffe auf z.B. PIT und Printer-Port oder stimmt das nicht? Sonst verzichte ich evtl. auf Windows-GUI und mache es im "MS-DOS-MODE" Für alle Anregungen vielen Dank, Grüße, Dierk
Wäre das nicht der klassische Einsatz eines µC? Dem überträgst du per COM lediglich die Aktion, z. B. Drehrichtung rechts, Schrittanzahl 1000. Das ganze Timing erledigt der Controller, genauso wie die Start- und Bremsrampen. Ich glaube nicht, daß Windows 98 echtzeitfähig ist. Michael
Nur am Rande: Die ernstgemeinten Windows-Versionen arbeiten standardmäßig mit Timerauflösungen von 15 bzw. 10 msec. Mit einem einfachen API-Aufruf kann die Timerauflösung auf 1 msec Genauigkeit erhöht werden ... Aber dann muss man - igittigitt - Hardware über Devicetreiber anfassen und das gehört sich ja nicht.
Hi, nur um das Timing-Problem nochmal zu konkretisieren: der Motor läuft zur Zeit unter DOS mit Uralt-Hardware und QBASIC(!!) mit bis zu 4 Umdrehungen pro Sekunde (240 U/min) schrittfehlerfrei, dh. es werden 4 * 400 = 1600 exakt getimte Schaltvorgänge pro Sekunde am Parallelport erforderlich - die Timing-Auflösung muß daher deutlich unter 1 ms liegen. µC ist momentan (noch) keine Lösung, da dadurch weitere Kosten entstehen - eigentlich sind in einem PC auch schon genug µC drin... wie z.B. der Timerbaustein - die Frage ist halt, wie man das System "umgeht" und sozusagen ein kleines ASM-Programm von ein paar Bytes zu fest definierten Zeitintervallen (="hard real time") unabhängig von Windows-Prozeßen aufrufen kann... die Abarbeitung ist dann so schnell daß es niemanden (auch keine anderen DAQ-Programme) stört. Evlt. den Windows-Timer-API hooken? Ich möchte halt so low-level wie möglich gehen ohne viel Overhead... Habe schon gelesen daß manche es über eine 16bit DLL versuchen um so aus der Protected-Mode-Falle (in der keine direkten Portzugriffe möglich sind) herauszukommen... Tipps?
Hi eben das will ja Windows und jedes andere ordentlich (nicht RT) Multiprozessing-OS verhindern. Du sollst nicht auf die Hardware zugreifen sondern immer über API-Funktionen des OS gehen. Und da kann dir der Scheduler halt dazwischenhauen wie er grade will und dir auch mal für 100ms den Prozessor entziehen. DOS ist kein Multiprozessing-OS. Da gehört dir der Prozessor ganz alleine bis du ihn wieder abgiebst. Wenn das für dich nicht aktzektabel ist mußt du auf etwas setzen was echte Echtzeit kann. Also z.B. die von Michael vorgeschlagene Lösung mit seperatem µC der nur noch Kommandos empfängt. Matthias
Hm, ok. Wie ist das mit "Sleep"? Anscheinend kann man die Granularität der Zeitscheibe bis auf 1 ms herabsetzen... das ist zwar nicht das was ich eigentlich wollte (ich wollte das System veranlassen, nach einer fixen Zeit mein Programm aufzurufen) aber vielleicht tut das auch, wenn man in der Zwischenzeit die Zeit pollt. Ich brauche die < 1ms Auflösung nur für den Fall, daß der Motor schnell vor- bzw. zurückfahren muß (so wie fast forward / rewind beim Tapedeck), dies ist die Ausnahmesituation, während der notfalls der Rechner auch 100% der Rechenzeit mit meinem Task verbringen darf. Die meiste Zeit sind die Anforderungen einiges geringer. Dann gibts da noch die directX-timer, zum Teil werden die zur Kontrolle der Framerate eingesetzt... mal schauen. Grüße, Dierk
Nein, wenn irgendwelches Hardwaregefummel mit Timerauflösungen < 1 msec erforderlich ist, dann sollte das in einem Devicetreiber geschehen. Alternativ könnte eine der verschiedenen verfügbaren "Realtime"-Erweiterungen verwendet werden - Windows ist schließlich kein Echtzeitbetriebssystem.
@ Dirk U, schau dir mal bei www.ros.de die Karte Stepper 8 an. Wenn du mit den Leistungen hinkommst, melde dich bei mir. Von den Karten haben wir noch einige hundert (aus einer Konkursmasse). Die Programmierung erfolgt dann über die serielle Schnittstelle vom PC. Und dann bist du die Timingprobleme los. Michael
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.