komplexes Arbeiten mit Schnittstelle TSerial von Toolbox

[EccoBravo]

Hallo,

schon wieder zum Thema Schnittstelle,

Dank Ihrer Unterstützung bin ich jetzt bei der Unstellung von Dejan ComPort auf Toolbox TSerial. Trotz aller Hilfe muss ich doch noch mal zu einer Frage zurückkommen:Wie ist es wenn ich über die serielle Schittstelle von einem Messgerät verschiedene Variablen abfrage?
TSerial fängt alle Antworten mit einer einzigen Routine Serial1EventChar() (mit Handshake) ab und schreibt die im einfachsten Falle in eine einzige Variable 's'.

Wie kriege ich es meinem Programm beigebogen, wenn ich vom Messgerät den Wert der Variable A haben will, dass dann mittels Serial1EventChar() diese auch auf der Delphi-Variable A abgelegt wird ?

Das war eigentlich der Kern aller meiner Fragen

Vielen Dank für Hilfe

EccoBravo

[DP-Maintenance]

Dieses Thema wurde von "Christian Seehase" von "Windows API" nach "VCL-Komponenten und Controls" verschoben.
Kein Windows-API Problem.

[EccoBravo]

ja, ... wie kriege ich das Antworts-Sammelsorium aus dem Sammelbecken 's' von EventChar verteilt auf die einzelnen Variablen A, B, C, ... ?

EccoBravo

[EccoBravo]

Hallo,

Ihr seid sicherlich sauer wegen meiner Penetranz, aber ich habe bei meiner Problematik eine wundersame Entdeckung gemacht, die ich nicht so richtig erklären kann:

Parallel zu meiner Programmierung probiere ich immer noch mit den Demo-Programmen von TSerial (Toolbox), dort funktioniert alles beim Auslesen einer einzigen Variable, wenn ich diese in einem Memo1.Text darstelle.
Nun habe ich versucht, die Sache in einem Edit1.Text anstelle in einem Memo1.Text darzustellen, doch dieses Edit1 blieb leer. Beim Versuch der gleichzeitigen Darstellung in Memo1.Text und Edit1.Text (auch bei vertauschter Reihenfolge) blieb immer das Edit1 leer und das Memo1 zeigte hingegen die Schnittstellenantwort immer richtig an.
Ich baute eine synchrone Wartezeile (Windows.Beep(300,300)) ein und machte folgende Beobachtung:
Während das Memo1 immer noch richtig die Antwort anzeigte, wurde im Edit1 die richtige Antwort nun für 300ms angezeigt und danach durch ein Hyroglyphen des CR LF abgelöst,
Da wird wohl des Übels Kern begraben sein, mein Schnittstellentransfer hat wohl auf den DelphiVarialben funktioniert, wurde durch die verwendeten TEdits nur falsch angezeigt.
Diese Funktion des TEdits beim Auslesen der Schnittstelle über TSerial.EventChar kann ich mir leider nicht erklären, kann mir jemand da helfen?

Vielen Dank

EccoBravo

[Guste1]

Hallo EccoBravo,

es wäre sehr hilfreich zu wissen mit welchem Gerät Du das versuchst.

Ich versuche es mit Hottinger Geräten, MGC und DK38. Beide geben, bei gleichem Treiber und gleicher Einstellung andere Ergebnisse aus.

Guste1

[EccoBravo]

Ja, Hallo,

ich versuche ein elektronisches Dosimeter zu bedienen (UNIDOS, PTW).

Aber meine Frage scheint sich davon entfernt zu haben, Folgerätsel ist nun der Besonderheitsunterschied zwischen TMEMO und TEDIT, wenn die darzustellende Zeichenkette mit #13#10 endet.

Vielen Dank

EccoBravo

[Generalissimo]

Hi,

also mit

Delphi-Quellcode:

var s:String

s:=TSerial1.ReceiveText;

kannst du ja die Schnittstelle auslesen.

Danach kannst du ja einfach mit Regulären Ausdrücken oder einfacher Stringbearbeitung die Variable
s bearbeiten.

Mach doch nach erhalt von s folgendes: Mess die Länge von s und schneide das #13+#10 einfach ab

[EccoBravo]

Danke, aber das tat ich bereits schon

Für das unterschiedliche Funktionieren der TMEMO und der TEDIT habe ich auch schon eine Erklärung herausgefunden:
Dazu habe ich mir die TSerial.EventChar nochmal vorgenommen: Ich habe hinter dem s (String) künstlich noch ein weiteres #13#10 gehangen nach dem Motto "mal sehen was im TMEMO passiert.

Delphi-Quellcode:

TSerial1EventChar();
begin
  s:=Serial1.ReceiveText;
  Memo1.Text:=s+#13#10;

end;

Die Antwortsdarstellung im TMEMO war zerhackt - das bedeutet, der Empfangsprozess im TSerialEventChar wird auch zerhackt. In der TMEMO-Darstellung wird später alles wieder zusammengefügt, sodass man nichts mehr davon merkt, nur TEDIT merkt etwas davon, es wird immer wieder neu geschrieben, was zu meinem früher beschriebenen Effekt führt.
Die Lösung wäre nun die, dass man den TSerialEventChar solange anhält, bis das Antworten des Messgeräte s vollkommen abgeschlossen ist. Dieses könnte man nur mit dem Abfragen der Zeichenkette #13#10 tun.

Wäre das eine Möglichkeit oder geht das noch besser ?

Danke

EccoBravo

[ibp]

wie sieht den überhaubt so ein string s aus den du bekommst?

abwararten vielleicht mit application.processmessages

[EccoBravo]

im MEMO bekomme ich zu sehen:

DA;06; 9.0s;0;3;00; 1.400742E-01;00; 1.989387E-01;00; 4.504735E-02;00; 2.067071E-01;00; 1.657059E-01;00; 2.250215E-02;22750

d.h. es müsste sein:

DA;06; 9.0s;0;3;00; 1.400742E-01;00; 1.989387E-01;00; 4.504735E-02;00; 2.067071E-01;00; 1.657059E-01;00; 2.250215E-02;22750#D#A



Wenn ich im TSerial1EventChar() ein künstliches #13#10 wie folgt
einfüge

Delphi-Quellcode:

TSerial1EventChar()
begin
    s:=Serial1.ReceiveText;
    Memo1.Text:=Memo1.Text+s+#13#10
end;

dann sieht der oben beschriebene zerhackte Antwortstext im MEMO1 wie folgt aus:

Delphi-Quellcode:

DA;06;    9.0s

;0;3;00; 1.400

742E-01;00; 1.

989387E-01;00;

 4.504735E-02;

00; 2.067071E-

01;00; 1.65705

9E-01;00; 2.25

0215E-02;22750

(Die Zeichenzahl jeder Zeile ist die selbe, Bezeichnung "Quellcode" fürs letzte Fenster irreführend, Habe Codefenster nur benutzt, weil es in der Darstellung auf die eränderte Anzahl der Leerzeichen ankommt - manschmal 4..oder 2..)

Vielen Dank und Grüsse

EccoBravo