Entwickler-Ecke
Sonstiges (Delphi) - TComm und RS232
Tobias31966 - Do 09.04.09 13:05
Titel: TComm und RS232
Hallo Leutz,
ich versuche seit einiger Zeit unter Delphi 6 die TComm-Komponente von M.Raab zu verwenden. Leider kann ich zwar Daten senden (Vom PC über Nullmodemkabel zum Laptop), diese aber dort nicht lesen. Ich sende einen String ('TestText') und empfange 3 CharReceived-Ereignisse der Länge (cbInQue) 1, 2 und 8. Sende ich nochmals, so erhalte ich wieder drei Ereignisse mit 9, 10 und 16 usw.
Die Auswertung des als @String-Typ übergebenen Puffers (TComm.Read gelingt auch nicht.
Wo stelle ich mich denn nur zu dumm an?
Xentar - Do 09.04.09 13:29
Ich kenn die Komponente nun nicht, selber verwende ich TApdComPort
aber da liegt doch bestimmt ein Beispielprogramm bei, oder? Wenn nicht, zeig wenigstens mal den Code, mit dem du die Daten emfängst.
Tobias31966 - Do 09.04.09 15:32
die komponente findest du in diesem fred, mehr habe ich nicht gefunden
Xentar - Do 09.04.09 15:44
1. Was ist ein Fred? Meinst du Thread? Dann sag das doch.
2. welchem "diesem"? Da ist kein Link..
3. Hast du uns immer noch keinen Quellcode gezeigt, der nicht funktioniert.
Tobias31966 - Fr 10.04.09 07:44
Danke für den link, irgendwie habe ich es nicht geschafft, den darzustellen.
Ja das ist die richtige Komponente.
ich habe also vom PC aus 'TestText' gesendet. Hier gehen einmalig 8 Zeichen weg.
Auf dem Laptop habe ich die drei Ereignisse überwacht. Es meldet sich nur das Ereignis 'OnCharReceived' und zwar dreimal.
Wenn ich in der Ereignisbehandlung dann versuche den Pufferinhalt zu lesen ´
Comm1.Read(@S, Length(S));
dann kommt da nur Mist an. Mit ein wenig Glück bekomme ich sogar eine Zugriffsverletzung hin.
jaenicke - Fr 10.04.09 07:55
Was hat denn Length(S) da zu suchen? Du musst da angeben wie viele Zeichen du lesen willst...
Nimm als Puffer am besten eine Variable vom Typ Char und gib an, dass du 1 Byte lesen willst jeweils...
Tobias31966 - Fr 10.04.09 13:25
und das in einer schleife, for 1 to cbInQue?
mmhh na gut, ich versuche es mal
jaenicke - Fr 10.04.09 17:54
Ja, genau. Du kannst natürlich auch einen String oder PChar nehmen, musst beim String aber dann auch vorher die Länge setzen (SetLength) bzw. beim PChar den Speicher reservieren.
Tobias31966 - Fr 10.04.09 21:47
das mi6t dem string hab ich probiert. Vorher mit SetLength(S, cbInQue). Da ich aber eigentlich ( zeichenlesen müßte, er aber drei mal mit 1, 2 und dann 8 kommt, hat es eben nicht geklappt.!
Tobias31966 - So 12.04.09 07:01
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
| procedure TForm1.Button3Click(Sender: TObject); var S: String; begin S := Edit1.Text; Comm1.Write(@S, Length(S)) end;
procedure TForm1.Comm2CharReceived(Sender: TObject; cbInQue: Cardinal); var S: String; begin ShowMessage(IntToStr(cbInQue) + ' Zeichen wurden empfangen'); SetLength(S, cbInQue); Comm1.Read(@S, cbInQue); Label4.Caption := 'Empfangen: >' + S + '<' end; |
Ich hatte gehofft, daß es so einfach wäre, ist es aber leider nicht...
Moderiert von
Narses: Quote- durch Delphi-Tags ersetzt
jaenicke - So 12.04.09 07:09
Ich habe da nix für den Com-Port zum Testen mehr da, deshalb musst du schon selbst debuggen. Ich nutze nur noch USB, da läuft das vollkommen anders. Der Quelltext ist schließlich da, da musst du selbst schauen was bei Read passiert und was da ggf. schief läuft. :nixweiss:
Tobias31966 - Di 14.04.09 04:44
Hallo Sebastian Jänicke,
danke für den Tip, aber genau das hat nicht funktioniert, da der Ausbnahmefehler, die Zugriffsverletzung für mich nicht zu debuggen ist. Ein derartiger Profi bin ich leider nicht.
und wenn ich die Write-Funktion verfolge bekomme ich einmalig gesendete 8 Bytes, aber ich finde die über die Read-Funktion auf dem Empfänger-PC nicht mehr!
Hallo Fabian Gärtner,
danke für diesen Link ich werde ihn gegebenenfalls einmal testen. Allerdings hat mir an der bisherigen Geschichte gerade die Komponente gefallen!
lg Tobias
jaenicke - Di 14.04.09 04:52
Tobias31966 hat folgendes geschrieben : |
danke für den Tip, aber genau das hat nicht funktioniert, da der Ausbnahmefehler, die Zugriffsverletzung für mich nicht zu debuggen ist. Ein derartiger Profi bin ich leider nicht. |
Naja, was passiert denn, wenn du einen Haltepunkt auf Comm1.Read(... setzt und dann ab da schrittweise durchgehst? Also wenn das Programm am Haltepunkt ankommt mit F7 in Read reingehst und dann weiter zeilenweise durchgehst (F8). So müsstest du genauer sehen was passiert.
Leider weiß ich nicht wie ich sonst helfen könnte, ich kann es eben wie gesagt nicht ausprobieren. Hast du einmal versucht immer nur ein Zeichen zu lesen? Kommt da was sinnvolles an?
Sonst wird auch häufig diese Komponente genannt, die recht einfach sein soll:
http://sourceforge.net/projects/comport/
Tobias31966 - Di 14.04.09 18:30
Die habe ich auch schon gesehen, die ist aber alles andere als einfach, weil ziemlich riesig. Mit F7 komme ich zwar ins Read rein, dort erhalte ich aber nur kryptische Dinge (die API-Funktionen), nichts was mein kleiner Kaninchenverstand auch nur ansatzweise begreift.
mikro1986 - Mi 15.04.09 15:01
Auch wenn es schon was länger her ist,
aber in deinem Quellcode hast du in der Ereignisroutine CharReceived von Comm2 Comm1 aufzurufen... ist das von dir so gewollt, oder ist da nen Zahlendreher drin??
gruß
mikro1986
Tobias31966 - Mi 15.04.09 15:31
Danke Mikro,
das ist nicht so gewollt, werde es gleich mal überprüfen. Aber das Problem bleibt sicher. Wenn ich am Laptop über eine Brücke Pin2/3 sende habe ich eh nur eine Comm verwendet.
mikro1986 - Mi 15.04.09 16:29
wäre aber logosch, wenns so net klappt... weil er wartet darauf, dass bei comm2 was passiert um comm1 zu lesen, da kannste net das richtige lesen können
Tobias31966 - Do 16.04.09 09:34
ja stimmt, ist auch bei zwei verwendeten Rechnern so. Wenn ich aber bei einem rechner teste und die Pins 2 und 3 brücke erhalte ich immer noch dieses unsinnige Ergebnis.
Ich versuce es schon mit PChar, kriege aber die Typwandlungen nicht so hin. Die Zugriffsverletzung entfällt schon mal, nun muß ich nur noch die Speicherinhalte lesen und deuten können.
mikro1986 - Do 16.04.09 11:45
du hast es gut, ich empfange gar nicht.... wie hast du das denn gemacht??
Ich habs so probiert, aber klappt nicht:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7:
| procedure TForm1.Comm1CharReceived(Sender: TObject; cbInQue: Cardinal); var s: String; begin ShowMessage(IntToStr(cbInQue) + ' Zeichen wurden empfangen'); memo1.Lines.Add(pchar(comm1.Read(@s[1],cbinque))); end; |
jaenicke - Do 16.04.09 23:34
mikro1986 hat folgendes geschrieben : |
Delphi-Quelltext 1:
| memo1.Lines.Add(pchar(comm1.Read(@s[1],cbinque))); | |
Read gibt das Ergebnis nicht zurück, sondern du übergibst den String s, in den dann das Ergebnis gelegt wird...
Und der muss vorher auch die entsprechende Größe haben.
mikro1986 - Fr 17.04.09 08:01
ich hab s ja als String definiert und und hab es auch schon anders versucht:
Comm1.read(@S[1],cbinque);
memi1.lines.add(s);
aber das klappt auch nicht...
mikro1986 - Fr 17.04.09 08:53
Bei mir ist das Problem ja, dass er ja nie in die Procedure
TComm1.ComCharReceived
reingeht... aber ka, warum nciht...
jaenicke - Fr 17.04.09 08:55
Du solltest dafür ein eigenes Thema aufmachen :!:
Jedenfalls wird dann eben nix empfangen, wenn du nicht gerade vergessen hast ComCharReceived bei OnReceived als Ereignis einzutragen. :nixweiss:
Tobias31966 - Fr 17.04.09 17:32
Also bei mir geht er in diese ComCharReceived rein, daß heißt, er meldet sich sobald über Rx Daten ankommen. Soweit so gut. Aber wenn ich einmalig Zeichen sende, dann empfängt er dreimalig Zeichen. Erst eines, dann zwei dann die gesendete Zahl. Und das begreife ich nicht. Andererseits ist es mir bisher unmöglich gewesen, diese Zeichen zu lesen.
Mit PChar kann ich zwar den Absturz vermeiden, was sinnvolles lesen aber auch nicht.
Es gibt ja innerhalb CharReceived zwei interessante Dinge. Zum einen die beim Aufruf übergebene Variable cbInQue und der Rückgabewert von TComm.Read (gelesene Zeichen). Die stimmen auch nicht überein, obwohl sie es für mein Verständnis tun sollten.
>Grübel<
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!