Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi Comport-Hardwareausgabe verlangsamt Programmablauf (https://www.delphipraxis.net/95430-comport-hardwareausgabe-verlangsamt-programmablauf.html)

christian.noeding 6. Jul 2007 10:22


Comport-Hardwareausgabe verlangsamt Programmablauf
 
Hallo Delphiler(innen)!

nun habe ich auch mal wieder ein Problem, bei dem mir keine gute Lösung einfallen will:


ich habe in meinem Programm (www.pcdimmer.de - Open-Source Delphi7-Programm) Plugins (normale Einsprung-DLLs), über die ich Hardware ansteuern kann. Jetzt ist denke ich jedem der schonmal mit dem Comport gearbeitet hat schonmal aufgefallen, dass das Programm kurz stockt, wenn es auf den Comport zugreift (extrem z.B. bei niedriger Baudrate). Da ich kontinuierlich Daten an Comports senden muss, verlangsamt sich dadurch der komplette Programmablauf.

Derzeit sende ich die Hardwareausgabe per normale Funktion an das Plugin. Diese DLL-Funktion ruft dann die Comport-Funktion auf. Bei mehreren aktiven Plugins gleichzeitig ist derzeit das Programm kaum noch nutzbar.

Gibt es eine Möglichkeit, wie ich die Hardwareausgabe und das Hauptprogramm so voneinander trennen kann, dass ich meine Daten an die DLL sende, diese dann z.B. über einen Ringpuffer die Daten in Ruhe ausgibt und zeitgleich mein Programm normal weiterarbeitet? Threads habe ich schon probiert, aber scheinbar bleibt die Comport-Komponente trotzdem ans Hauptprogramm gefesselt...




Vielen Dank für ein paar Vorschläge!

Christian :)

DGL-luke 6. Jul 2007 10:36

Re: Comport-Hardwareausgabe verlangsamt Programmablauf
 
Also die Comport-Kompo in nen Thread auszulagern sollte helfen, wenn nicht dein komplettes system stockt. wie hast du das denn bis jetzt probiert?

christian.noeding 6. Jul 2007 10:58

Re: Comport-Hardwareausgabe verlangsamt Programmablauf
 
Liste der Anhänge anzeigen (Anzahl: 1)
Hi :)

Ich habe meinen Thread so erstellt:

Delphi-Quellcode:
  TSendRs232Event = procedure () of object;
  TSendRs232Thread = class(TThread)
  private
    FSendRs232Event:TSendRs232Event;
  protected
    procedure Execute; override;
  public
    constructor create(SendRs232Event:TSendRs232Event);
  end;

{...}

  type
  TConfig = class(TForm)
{...}
    comport: TCommPortDriver;
    procedure SendRs232();
{...}
  public
    rs232frame:array of array[0..5] of Byte;
    rs232frame_locked:boolean;
    Thread_closed:boolean;
  end;
Und das hier ist der Code für den Thread:

Delphi-Quellcode:
//-------------------------------------------------

constructor TSendRs232Thread.Create(SendRs232Event:TSendRs232Event);
begin
  inherited create(false);
  FSendRs232Event:=SendRs232Event;
  Priority := tpHigher;
  FreeOnTerminate := true;
end;

procedure TSendRs232Thread.Execute;
begin
  inherited;
   config.Thread_closed:=false;
  config.SendRs232();
   config.Thread_closed:=true;
  Terminate;
end;

procedure Tconfig.SendRs232();
begin
  repeat
    if (not rs232frame_locked) then
    begin
      rs232frame_locked:=true;
      if length(rs232frame)>0 then
      begin
        config.comport.SendData(@config.rs232frame[length(rs232frame)-1],6);
        setlength(rs232frame,length(rs232frame)-1);
      end;
      rs232frame_locked:=false;
    end;
    sleep(1);
  until shutdown;
end;
//-------------------------------------------------
Das Hauptprogramm hat dann den Neuen zu sendenden Wert in eine globale Variable (rs232frame) kopiert:

Delphi-Quellcode:
  with config do
  begin
    repeat
      if not rs232frame_locked then
      begin
        rs232frame_locked:=true;
        setlength(rs232frame,length(rs232frame)+1);
        for i:=0 to 5 do
          rs232frame[length(rs232frame)-1][i]:=rs232frame_new[i];
        rs232frame_locked:=false;
      end;
      sleep(1);
    until rs232frame_locked=false;
  end;



So, ich weiß, dass derzeit folgendes unsinnig ist:

a) die repeat-Schleife verzögert das Hauptprogramm ebenfalls - muss mich aber erst mal mit Ringpuffern auseinandersetzen -> also anderes Problem
b) derzeit liegt die Comport-Komponente noch in der Hauptform. "comport: TCommPortDriver" müsste doch irgendwie in den Thread rein, oder?


ciao,
Christian!


Alle Zeitangaben in WEZ +1. Es ist jetzt 21:18 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz