Hallo zusammen,
Zwecks Steuerung eines Schrittmotors habe ich für eine TButton-Komponente eine Routine geschrieben, die das für die Steuerung des Motors erforder-
liche Bitmuster am Parallelport ausgibt:

Globale Deklaration:

zusammenfalten · markieren

Delphi-Quellcode:

var
  Form1: TForm1;
  ...
  Filter:byte;
  Ende: Boolean;

procedure Tform1.DREH_RECHTSClick(Sender: TObject);
begin
  ...Anweisungen
  Repeat
    ...Anweisungen
    ...
    If Filter = 1 then
      Ende:=True;
  Until Ende;
  ...Anweisungen
end;

Die Routine läuft bzw. der Schrittmotor läßt sich einschalten und dreht wie gewünscht. Das Problem ist allerdings, dass sich die Routine bzw. der Motor nicht über einen zweiten Aus-Schalter(TButton) abschalten läßt, da das Formular, in dem sich die Schalter (DREH_RECHTS und ein weiterer AUS) befinden deaktiviert ist, sobald die Repeat-Until (Endlos!)Schleife läuft. Die Ereignis-Behandlungsroutine für den DREH_RECHTS-Button wird ja nicht bendet.
Mittels Filter sollte ursprünglich die Information abgefragt werden, ob AUS geklickt wurde. Für eine TButton-Abfrage gibt es zwar etliche Möglichkeiten, nur sind diese alle sinnlos, wenn sich der AUS-Button
bei laufendem Motor nicht schalten läßt. Da sich das Problem weder mit Mausabfragen noch durch die Verwendung eines weiteren Formulars lösen ließ (Die Endlosschleife deaktiviert sämtliche Formulare der Anwendung), habe ich eine zweite Anwendung geschrieben, mit welcher sich das Strobe-Bit vom Steuer-Registers des ParallelPorts schalten läßt.
Das ursprüngliche Programm fragt jetzt über Filter das Strobe-Bit ab und der Motor läßt sich so mittels dieser Strobe-Bit-Änderung über das andere Programm wieder ausschalten.
Ganz abgesehen davon, dass dies wohl keine sehr elegante Lösung für obiges Problems ist, besteht ja weiterhin das Problem, dass eine Manipu-lation des drehenden Motors also eine Drehzahlsteuerung während des Betriebs so noch nicht möglich ist. Für Tipps im voraus vielen Dank.

Willkommen in der Delphipraxis

Gehe ich recht in der Annahme, daß dein Problem hauptsächlich darin besteht, die Anwendung quasi nicht mehr bedienen zu können, während deine Repeat-Schleife abläuft? Dafür gibt es eine ganz einfache Lösung: Du mußt dafür sorgen, daß währenddessen weiterhin Windows-Messages abgearbeitet werden können. Dafür gibt es den Befehl Application.ProcessMessages.

Wenn du Code postest, tust du allen potentiellen Helfern einen großen Gefallen, diesen in die sogenannten Delphi-Tags einzubetten. Dazu markierst du den Code, den du in den Foren-Editor hineinkopiert oder -geschrieben hast und drückst dann den Button mit dem Delphi-Helm. Dadurch bleibt die Formatierung des Codes erhalten, wodurch dieser leichter lesbar wird.

zusammenfalten · markieren

Delphi-Quellcode:

Globale Deklaration:
var
  Form1: TForm1;
  ...
  Filter:byte;
  Ende: Boolean;

procedure Tform1.DREH_RECHTSClick(Sender: TObject);
begin
  ...Anweisungen
  Repeat
    ...Anweisungen
    ...
    If Filter = 1 then
      Ende:=True;
    Application.ProcessMessages; // z.B. hier die Botschaftswarteschlange abarbeiten
  Until Ende;
  ...Anweisungen
end;

Hallo und willkommen in der DP. Damit hast du dir dein eigenes Weihnachtsgeschenk gemacht

Das von Perlsau angesprochene Application.ProcessMessages ist natürlich ein Weg, die Anwendung in de meisten Fällen wieder reagieren zu lassen. [EDIT]Unter Umständen kann dann aber dein Motor anfangen zu stocken. Je nachdem wie das Laufen des Motors implementiert ist.[/EDIT] Zum Test kannst du das auch einfach mal in deine Repeat Schleife einbauen und das ausprobieren. Wenn es dann funktioniert, solltest du dir darüber Gedanken machen, das alles in einen sogenannten Thread auszulagern. Threads sind extra dafür gemacht, dass Aktionen im Hintergrund ausgeführt werden und die Anwendung trotzdem noch reagiert. Hier mal ein kleines Thread Tutorial aus dem Delphi Treff. Es lohnt sich, das Tutorial mal durchzuarbeiten um die Grundfunktionalität eines Threads zu verstehen.

Moin...

Zitat:

Wenn es dann funktioniert, solltest du dir darüber Gedanken machen, das alles in einen sogenannten Thread auszulagern.

Imho ist ein Thread für das Vorgehen zwingend notwendig. Bei der anderen Variante ist der Motor betroffen wenn irgend etwas an der GUI hakt oder ähnliches (HTTP Abfrage, DB Abfrage sind z.B. standardmäßig blockierend)...

Tipp: Was kostet es mehr wenn man es gleich richtig macht.

Der TE scheint gerade erst mit der Programmierung angefangen zu haben, von daher ist Application.ProcessMessages als schnelle Erfolgslösung schon mal gut.

=> Make it work

Der Hinweis auf einen Thread ist allerdings auch zwingend.

=> Make it right

Zitat von Sir Rufo:

Der TE scheint gerade erst mit der Programmierung angefangen zu haben, von daher ist Application.ProcessMessages als schnelle Erfolgslösung schon mal gut.

=> Make it work

Der Hinweis auf einen Thread ist allerdings auch zwingend.

=> Make it right

Genau das war der Hintergrund meiner Antwort.

"Make it work -> make it Right"
Vorsicht mit solchen Parolen. Wenn's denn erst mal läuft, kriegst Du vom sogenannten Management selten die Erlaubnis, es richtig zu machen. Und so lebt der Mist ewig fort. Make it working the right way.

Nochmals Danke für die geposteten Tipps, werde sie mit Sicherheit noch an- wenden (müssen!).Inzwischen habe ich das Problem quasi halb gelöst. Und zwar
habe ich die Steuerdaten für die verschiedenen Betriebszustände des Motors
in eine Steuerdatei geschrieben, die vom Motorprogramm ständig abgefragt wird. Damit ist über zwei While-Schleifen sowohl ein Ein-Ausschalten als auch eine Drehzahländerung möglich WÄHREND der Motor läuft. Da das ganze aber nach wie vor nur mit zwei Programmen funktioniert und sich zu dem das Motorprogramm mit den Endlos-Schleifen nur mit dem Task-Manager beenden läßt, wird ApplicationProcessMessages bestimmt von mir verwendet werden. Mit dem Thema "Threads" habe ich mich noch nicht beschäftigt. Von daher werden die Links zu dem Thema wohl hilfreich sein.