komisches Verhalten der RS232-Schnittstelle/ ComPort

[BAMatze]

Hallo und guten Morgen an alle,

Also hatte schon länger ein paar Probleme mit meinem Programm, die ich mir bisher nicht erklären konnte und habe mir eine kleine Erweiterung gebaut, bei der ich ein paar Überprüfungen wärend des Betriebes mache. Unter anderem ist dort ein Comport-scanner dabei, der mir auch Events erzeugt, wenn ein Comport dazu kommt. Dies funktioniert auch sehr gut, ALLERDINGS habe ich das Problem, dass bei einem Gerät der Comport nach 2-3 Sekunden anscheinend wieder verschwindet.
Ich benutze die ganz normalen Befehle für dieses Gerät und initialisieren/ terminiere dort über open- und close-Befehle.
Jetzt meine Frage (habe mit der RS232-Schnittstellenprogrammierung noch keine Erfahrungen): Kann es sein, dass der Comport (normal wird er mit anstecken des USB-Steckers registriert) verschwindet, wenn der close-Befehl an den Microcontroler des Gerätes geschickt wird?

Hoffe jemand kann mir dort helfen oder kennt ne gute Quelle/ Tut wo man sich das im Groben mal aneignen kann.
Vielen Dank im Voraus
BAMatze

[EDIT]
also ich verwende folgende Prozedure zu Comport-Findung:

Delphi-Quellcode:

function TComport.ComPort(ComPortNummer:  byte): longbool;
var TestHandle : integer;
begin TestHandle :=CreateFile(PChar('\\.\COM'+IntToStr(ComPortNummer)),GENERIC_READ or GENERIC_WRITE,0,
                              nil,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,LongInt(0));
  if (TestHandle <= 0) then Result := false
  else begin 
         Result := true; 
         CloseHandle(TestHandle); // <-- kann es eventuell an dieser Zeile liegen?
       end;
end;

Bei diesem schließe ich ja das Handle wieder, nachdem ich den Comport gefunden hab.

[/Edit]

[BAMatze]

Also das Problem ist derzeit noch nicht gelöst.

Folgende weitere Erkenntnisse konnte ich bis zu dem jetzigen Zeitpunkt gewinnen:
Es liegt definitiv an meinem Programm, denn der Comport bleibt für Windows (im Gerätemanager) weiter aktiv, wärend die Routine, die ich im ersten Post gegeben hab diesen nach der Anmeldung sofort wieder als abgeschalten erkennt. Also bleibt für mich eigentlich nur die Frage welcher Befehl in der Lage ist dies zu bewerkstelligen oder ob es andere Routinen gibt die ComPorts zu ermitteln.

[Edit] Ob es an der besagten Zeile liegt, kann ich derzeit noch nicht sagen, da ich beim auskommentieren diese Befehls immer einen Indexüberlauf in einer Stringlist erzeuge und dort noch suche, warum dies nur bei auskommentierter Zeile so ist [/Edit]

[Edit2] also hab das ganze Programm jetzt deutlich vereinfacht und lasse mir Anstelle von sich ändernden Comports immer nur die Liste der gefundenen über diese Funktion darstellen und diese Liste ist korrekt und vollständig die ganze Zeit. Außerdem MUSS die Zeile, nach der ich im ersten Teil gefragt habe drin sein, da sonst überhaupt kein Comport gefunden wird. Also liegt irgendwo in dem Programmcode von mir der hier noch nicht gepostet wurde ein Fehler. Werde versuchen, diesen zu finden und auch heir mal zu ergänzen. [/Edit]

[LDericher]

Hi BAMatze

Ich hab jetzt zugegebenermaßen nicht alles gelesen, aber:

Vielleicht hilft dir das hier weiter: http://www.delphipraxis.net/internal...t.php?t=136188

Peace,
LDer.

P.S.: BAM-Atze oder BA-Matze?

[BAMatze]

Danke Dir,

lese ich mir heute Abend zu Hause mal in Ruhe durch. Zu deinem Ps: BAM - Matze (ein M hab ich mir aus Speichergründen für die DP gesparrt 8) )

BAM(M)atze ^^

[sx2008]

Was ist dass denn?if (TestHandle <= 0) then Result := false Ich meine du musst das Handle schon mit der Konstante INVALID_HANDLE_VALUE vergleichen; alles andere ist sehr unsauber.
Stell' dir vor, was passiert, wenn Windows ein gültiges Handle mit gesetzem höchstwertigen Bit zurückliefert...
Und der Typ eines Handles ist auch nicht integer sondern THandle.

[BAMatze]

Also die oben aufgeführte Procedure stammt nicht aus meiner Feder, sondern hab ich hier an mehreren Stellen in der DP gefunden. Werde natürlich auf deinen Hinweis hin natürlich versuchen diese entsprechend umzuwandeln.

[BAMatze]

Ok folgende Erkenntnise: Das verschwinden des ComPorts in der Liste, die ich mit der oben aufgeführten Procedure erstelle, scheint in meinem Fall ok zu sein (liegt anscheinend an dem Quellcodein der DLL). Die einzigen 2 Dinge, die ich nicht machen darf sind, 2 mal die gleiche Open-Funktion der DLL auf den Comport anzuwenden -> die Kommunikation crashed und ich kann nichts mehr machen. Desweiteren muss ich nach der Open-Prozedure mindestens 1 Sek warten, bis der erste Befehl raus geht, damit dieser bearbeitet wird.
Wenn ich dies beachte, kann ich mit dem Gerät arbeiten.

Danke euch trotzdem für die Hilfe, werde gerade das mit dem Handle nochmal überarbeiten.
BAMatze

[BAMatze]

Also wollte hier nochmal folgende Ergänzung machen für das Problem an den ComPorts. Nach einer etwas intensiveren Suche habe ich noch folgende alternative Routine gefunden, die die Comports auflistet. Diese scheint auch deutlich besser zu funktionieren. bei der Verwendung dieser Routine verschwindet der ComPort/ RS232-Schnittstelle nämlich nicht, wenn die open-Funktion der DLL aufgerufen wird. dadurch konnte ich die Problematik, die hier gestellt war, lösen.

alternative Routine (hier aus der DP):

Delphi-Quellcode:

procedure TComport.EnumComPorts(Ports: TStrings);
var
  KeyHandle: HKEY;
  ErrCode, Index: Integer;
  ValueName, Data: string;
  ValueLen, DataLen, ValueType: DWORD;
  TmpPorts: TStringList;
begin
  ErrCode := RegOpenKeyEx(HKEY_LOCAL_MACHINE, 'HARDWARE\DEVICEMAP\SERIALCOMM',
    0, KEY_READ, KeyHandle);
  if ErrCode <> ERROR_SUCCESS then
    raise Exception.Create('Fehler beim Registry öffnen!');
  TmpPorts := TStringList.Create;
  try
    Index := 0;
    repeat
      ValueLen := 256;
      DataLen := 256;
      SetLength(ValueName, ValueLen);
      SetLength(Data, DataLen);
      ErrCode := RegEnumValue(
        KeyHandle,
        Index,
        PChar(ValueName),
        Cardinal(ValueLen),
        nil,
        @ValueType,
        PByte(PChar(Data)),
        @DataLen);

      if ErrCode = ERROR_SUCCESS then
      begin
        SetLength(Data, DataLen - 1);
        TmpPorts.Add(Data);
        Inc(Index);
      end
      else
        if ErrCode <> ERROR_NO_MORE_ITEMS then
          raise Exception.Create('Fehler Registry auslesen!');

    until (ErrCode <> ERROR_SUCCESS) ;
    TmpPorts.Sort;
    Ports.Assign(TmpPorts);
  finally
    RegCloseKey(KeyHandle);
    TmpPorts.Free;
  end;
end;

BAMatze