Exception während RS232 Datenempfang

[akuk]

Zwei PC kommunizeren über RS232. PC1 sendet laufend Daten an PC2.
Eine Exception wird gemeldet (System), trotzdem werden die Daten
weiterhin übermittelt und deren Empfang Quittiert.
Dagegen das Programm-Hauptablauf ist blockiert.

Exception im "System" :
CALL FreeMem, InvalidPointer, "ungültige Zeigeroperation"
siehe Beilage.
Was kann die Ursache sein ? wo soll man suchen ?

[Rollo62]

RS232 kann zu beliebigen Zeiten kommen, müsste also ThreadSicher behandelt werden bevor Du das irgendwo weiterverarbeitest.
Probier das Mal mit TThread.ForceQueue zu entkoppeln.
ce

[zeras]

Ich nehme das hier für RS232 Kommunikation und bin zufrieden damit.

[Medium]

Eine kostenfreie Alternative, die ich seit Jahren immer mal wieder erfolgreich einsetze ist TPAPro. Zuletzt allerdings mit D2007 - ob und wie gut das mit den neuen Delphis spielt kann ich leider nicht sagen. (Wird für mich über kurz oder lang aber sicher auch mal interessant.)


Edit: Das auf Sourceforge scheint veraltet zu sein. Brandaktuelle Versionen habe ich gerade auf GitHub gesehen!

[himitsu]

Zitat von Rollo62:

RS232 kann zu beliebigen Zeiten kommen, müsste also ThreadSicher behandelt werden bevor Du das irgendwo weiterverarbeitest.
Probier das Mal mit TThread.ForceQueue zu entkoppeln.
ce

Das kommt drauf an. Ja, viele ComPort-Komponenten haben einen Thread, der die Daten empfängt und vom hardwarepuffer in einen Softwarepuffer kopiert,
aber ein muss ist das nicht.

Aber auch diese komponenten aben meisten keinen unendlich großen Puffer, also muß dessen Programm somit auch die Daten von dort abrufen, damit die Komponente nicht aufhört den Hardwarepuffer zu leeren.


Per se, also ohne Hardwarehandshake, ist die serielle Komunikation meistens ohne Rückkopplung, also niemand bekommt mit, wenn der Andere die "empfangenen" Daten überhaupt verarbeitet, bzw. ob überhaupt jemand zuhört. (es sei denn der andere Antwortet und man wertet das aus)

[Rollo62]

@himitsu
Stimmt, aber mit aktuellen PC's habe ich da eigentlich keine Probleme mehr gehabt,
die sind einfach viel schneller als RS232.
Kommt natürlich auf die Baudrate an.
Beim Debuggen können die Buffer natürlich schon vollaufen im Hintergrund.
Der Fehler kann natürlich trotzdem noch alle möglichen Ursachen haben, war jetzt nur eine Idee.

Ich benutze deswegen einen eigenen Ringbuffer, der threadsicher reinschreibt und auslesen kann,
so das In- und Out völlig entkoppelt sind.
Ich denke mal das einige COM Komponenten das schon drin haben, die Hinweise und Links sind also richtig.
Ich weiss aber nicht was der TE nutzt und wie er das umsetzt.

[akuk]

Hallo
Das rs232 lauft im Thread, darum lauft es weiter auch nach der Exception.
Die Exception passiert also im Hauptablauf. Nur handelt sich um SystemException
,wie finde ich heraus was ist die Ursache.
Das was Debugger zeigt hilft nicht weiter, da ist man schon im System.
Siehe Beilage.

Kan man im RAD Delphi Rio tracen, ich habe es nicht gefunden ?

[Der schöne Günther]

Schau doch mal im Stacktrace kurz darüber, _UStrClr und so. Und das läuft in irgendeiner Fensterprozedur eines TWinControl . Steckst du irgendwie rohe Bytes in Strings oder sowas?

[akuk]

Hallo schöne Günter
Ich bin ein Anfänger, wo finde ich das UstrCtr resp TWinControl.
ich hab überall gesucht aber nicht gefunden.
Start
Ueberwachte Ausdrcke ?
Parameter ?

ja es passiert in eine Fensteprocedur beim werte abfüllen aber wo habe ich bis
jetzt nicht gefunden.
es sollen Werte die vom Rs232 Thread (byte array) im Fenster Angezeigt werden.
ich hab überall BP gesetzt aber das hat nicht funktioniert.

Besten Dank zum voraus.

[himitsu]

Manchmal bleibt der Debugger auch im falschen Thread stehen, bzw. die eigentliche Fehlerursache kann von wo anders her kommen.
Strg+Alt+T: In der Threadliste kannst du mit Doppelklick umschalten und siehst im Stacktrace dann auch die anderen Threads.