![]() |
komisches Verhalten der RS232-Schnittstelle/ ComPort
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:
Bei diesem schließe ich ja das Handle wieder, nachdem ich den Comport gefunden hab.
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; [/Edit] |
Re: komisches Verhalten der RS232-Schnittstelle/ ComPort
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] |
Re: komisches Verhalten der RS232-Schnittstelle/ ComPort
Hi BAMatze
Ich hab jetzt zugegebenermaßen nicht alles gelesen, aber: Vielleicht hilft dir das hier weiter: ![]() Peace, LDer. P.S.: BAM-Atze oder BA-Matze? :D |
Re: komisches Verhalten der RS232-Schnittstelle/ ComPort
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 ^^ |
Re: komisches Verhalten der RS232-Schnittstelle/ ComPort
Was ist dass denn?
Delphi-Quellcode:
Ich meine du musst das Handle schon mit der Konstante INVALID_HANDLE_VALUE vergleichen; alles andere ist sehr unsauber.
if (TestHandle <= 0) then Result := false
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. |
Re: komisches Verhalten der RS232-Schnittstelle/ ComPort
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.
|
Re: komisches Verhalten der RS232-Schnittstelle/ ComPort
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 |
Re: komisches Verhalten der RS232-Schnittstelle/ ComPort
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:
BAMatze
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; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz