+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Instrument IO & VISA (/Forum-Instrument-IO-VISA)
+---- Thema: Pufferüberlauf bei serieller Kommunikation (/Thread-Pufferueberlauf-bei-serieller-Kommunikation)
Pufferüberlauf bei serieller Kommunikation - Yantit - 21.06.2010 08:26
Okay, hier zunächst einmal die Initialisierung:
[attachment=27254]
Und desweiteren noch mal einen Screenshot des Graphen, wenn ich das Abschlusszeichen AUSschalte...
[attachment=27255]
Hier schlecht zu sehen, aber der breitere Peak sollte fest auf 80 MHz stehen, allerdings läuft dann der Graph von links nach rechts durch...
Außerdem hier noch mal wie gewünscht eine Kopie einer Messwertabfrage, wie sie mir der Analyzer auf dem Hyperterminal zurückliefert...
<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space:pre;overflow:auto'>> :trac:data? trace1
-88.26 dBm,-84.68 dBm,-80.73 dBm,-75.12 dBm,-79.46 dBm,-80.57 dBm,-82.73 dBm,-86
.85 dBm,-88.76 dBm,-81.43 dBm,-77.36 dBm,-82.87 dBm,-84.86 dBm,-81.86 dBm,-90.65
dBm,-88.89 dBm,-79.70 dBm,-83.77 dBm,-80.45 dBm,-82.90 dBm,-82.34 dBm,-86.03 dB
m,-81.43 dBm,-93.17 dBm,-85.10 dBm,-82.31 dBm,-83.39 dBm,-77.53 dBm,-85.85 dBm,-
85.00 dBm,-81.54 dBm,-87.79 dBm,-80.49 dBm,-79.85 dBm,-79.94 dBm,-85.17 dBm,-78.
88 dBm,-79.10 dBm,-86.73 dBm,-86.86 dBm,-82.85 dBm,-84.60 dBm,-86.80 dBm,-88.20
dBm,-77.73 dBm,-82.97 dBm,-87.12 dBm,-89.17 dBm,-82.25 dBm,-79.91 dBm,-88.66 dBm
,-87.91 dBm,-85.41 dBm,-78.76 dBm,-80.31 dBm,-86.02 dBm,-82.37 dBm,-79.82 dBm,-8
3.63 dBm,-88.93 dBm,-79.49 dBm,-82.29 dBm,-84.12 dBm,-85.36 dBm,-87.38 dBm,-78.0
9 dBm,-84.33 dBm,-79.58 dBm,-85.98 dBm,-86.05 dBm,-98.94 dBm,-91.17 dBm,-89.02 d
Bm,-77.35 dBm,-81.11 dBm,-87.04 dBm,-80.41 dBm,-84.91 dBm,-82.42 dBm,-78.97 dBm,
-80.76 dBm,-82.34 dBm,-81.92 dBm,-80.41 dBm,-81.77 dBm,-80.12 dBm,-86.56 dBm,-81
.21 dBm,-85.77 dBm,-83.51 dBm,-86.74 dBm,-91.28 dBm,-84.56 dBm,-87.65 dBm,-88.11
dBm,-86.90 dBm,-79.05 dBm,-81.65 dBm,-75.27 dBm,-76.69 dBm,-84.18 dBm,-84.12 dB
m,-81.87 dBm,-83.73 dBm,-91.95 dBm,-82.83 dBm,-80.63 dBm,-84.63 dBm,-81.82 dBm,-
83.55 dBm,-83.14 dBm,-86.53 dBm,-84.37 dBm,-76.83 dBm,-84.37 dBm,-85.58 dBm,-87.
45 dBm,-83.63 dBm,-81.76 dBm,-89.04 dBm,-81.05 dBm,-88.92 dBm,-83.03 dBm,-85.82
dBm,-85.43 dBm,-88.85 dBm,-77.14 dBm,-84.42 dBm,-80.10 dBm,-82.58 dBm,-87.68 dBm
,-84.14 dBm,-86.94 dBm,-87.53 dBm,-78.16 dBm,-84.96 dBm,-80.35 dBm,-83.95 dBm,-7
9.57 dBm,-80.74 dBm,-79.51 dBm,-80.40 dBm,-82.07 dBm,-86.70 dBm,-86.58 dBm,-80.7
8 dBm,-81.28 dBm,-80.75 dBm,-88.62 dBm,-80.18 dBm,-84.68 dBm,-77.24 dBm,-88.01 d
Bm,-85.77 dBm,-87.78 dBm,-82.56 dBm,-80.37 dBm,-84.93 dBm,-85.81 dBm,-85.36 dBm,
-84.67 dBm,-80.50 dBm,-82.46 dBm,-81.36 dBm,-81.04 dBm,-79.26 dBm,-76.18 dBm,-77
.54 dBm,-76.24 dBm,-74.16 dBm,-73.61 dBm,-73.08 dBm,-71.31 dBm,-70.10 dBm,-69.31
dBm,-68.13 dBm,-66.51 dBm,-65.42 dBm,-63.76 dBm,-62.68 dBm,-61.08 dBm,-59.67 dB
m,-58.46 dBm,-56.95 dBm,-55.69 dBm,-54.05 dBm,-52.74 dBm,-51.36 dBm,-50.13 dBm,-
48.65 dBm,-47.40 dBm,-46.33 dBm,-45.09 dBm,-43.99 dBm,-42.97 dBm,-42.12 dBm,-41.
40 dBm,-40.79 dBm,-40.31 dBm,-40.04 dBm,-39.93 dBm,-39.90 dBm,-40.16 dBm,-40.48
dBm,-40.89 dBm,-41.52 dBm,-42.32 dBm,-43.24 dBm,-44.26 dBm,-45.29 dBm,-46.43 dBm
,-47.60 dBm,-48.69 dBm,-50.03 dBm,-51.38 dBm,-52.59 dBm,-53.93 dBm,-55.23 dBm,-5
6.69 dBm,-57.79 dBm,-59.16 dBm,-60.46 dBm,-61.61 dBm,-63.59 dBm,-64.31 dBm,-65.7
7 dBm,-66.58 dBm,-67.68 dBm,-68.87 dBm,-69.87 dBm,-70.93 dBm,-72.17 dBm,-73.26 d
Bm,-74.71 dBm,-75.84 dBm,-75.82 dBm,-77.57 dBm,-78.26 dBm,-79.21 dBm,-80.60 dBm,
-80.09 dBm,-83.17 dBm,-80.34 dBm,-83.43 dBm,-84.21 dBm,-84.55 dBm,-86.83 dBm,-82
.79 dBm,-86.40 dBm,-78.47 dBm,-85.30 dBm,-81.12 dBm,-77.42 dBm,-82.87 dBm,-83.24
dBm,-84.50 dBm,-85.71 dBm,-88.34 dBm,-89.26 dBm,-86.53 dBm,-83.04 dBm,-88.09 dB
m,-81.99 dBm,-85.14 dBm,-81.10 dBm,-79.12 dBm,-86.65 dBm,-82.87 dBm,-85.24 dBm,-
78.48 dBm,-89.15 dBm,-84.91 dBm,-87.40 dBm,-85.21 dBm,-83.87 dBm,-83.37 dBm,-87.
76 dBm,-82.93 dBm,-90.75 dBm,-84.14 dBm,-87.75 dBm,-82.89 dBm,-85.03 dBm,-87.03
dBm,-88.91 dBm,-80.46 dBm,-85.18 dBm,-84.46 dBm,-79.53 dBm,-85.54 dBm,-78.76 dBm
,-84.95 dBm,-82.99 dBm,-79.72 dBm,-79.42 dBm,-78.14 dBm,-83.02 dBm,-80.39 dBm,-8
4.67 dBm,-91.23 dBm,-83.30 dBm,-79.94 dBm,-87.81 dBm,-84.63 dBm,-86.44 dBm,-83.5
3 dBm,-78.26 dBm,-85.39 dBm,-81.90 dBm,-84.47 dBm,-83.09 dBm,-87.64 dBm,-83.79 d
Bm,-81.12 dBm,-85.41 dBm,-81.80 dBm,-86.94 dBm,-83.91 dBm,-88.10 dBm,-93.36 dBm,
-84.99 dBm,-84.57 dBm,-88.51 dBm,-88.01 dBm,-83.59 dBm,-85.90 dBm,-85.77 dBm,-93
.86 dBm,-82.62 dBm,-84.81 dBm,-81.03 dBm,-85.45 dBm,-84.92 dBm,-83.09 dBm,-81.22
dBm,-87.12 dBm,-92.34 dBm,-82.23 dBm,-79.31 dBm,-78.09 dBm,-82.72 dBm,-90.23 dB
m,-85.06 dBm,-76.76 dBm,-83.96 dBm,-86.55 dBm,-83.67 dBm,-93.23 dBm,-81.81 dBm,-
90.46 dBm,-80.61 dBm,-84.59 dBm,-82.08 dBm,-79.31 dBm,-86.18 dBm,-87.26 dBm,-78.
74 dBm,-89.03 dBm,-84.53 dBm,-83.63 dBm,-77.63 dBm,-79.91 dBm,-81.51 dBm,-84.33
dBm,-88.14 dBm,-80.12 dBm,-84.01 dBm,-88.63 dBm,-84.08 dBm,-86.09 dBm,-83.13 dBm
,-82.89 dBm,-85.18 dBm,-92.36 dBm,-85.93 dBm,-90.58 dBm,-89.38 dBm,-83.67 dBm,-8
0.22 dBm,-78.97 dBm,-81.61 dBm,-83.04 dBm,-84.13 dBm,-77.83 dBm,-83.12 dBm,-82.2
5 dBm,-84.08 dBm,-83.67 dBm,-80.06 dBm,-83.81 dBm,-83.71 dBm,-87.95 dBm,-78.37 d
Bm,-81.45 dBm,-81.42 dBm,-82.93 dBm,-81.91 dBm,-84.75 dBm,-85.55 dBm,-81.29 dBm,
-79.74 dBm,</div>
Pufferüberlauf bei serieller Kommunikation - Yantit - 21.06.2010 08:38
Okay, dann versuche ich jetzt nochmal, eure Tipps/Hilfen für mich zusammen zu fassen:
- Grundsätzliches Problem: Man weiß zu wenig über den Aufbau des "Antwortstrings", sprich welches Abschlusszeichen, etc.
- Dadurch weiß man nun nicht genau, wo nun der String konkret endet, d. h. man liest möglicherweise Unsinn aus bzw. Teile des nachfolgenden Strings
- Ein Ansatz könnte sein, erst das Echo des Kommandos auszulesen, dies zu detektieren und dann nochmal nach einem Leeren des Puffers noch mal die 4413 Bytes der eigentlichen Antwort zu lesen.
Hoffe, ich habe erfassen können, was ihr genau meint...
Pufferüberlauf bei serieller Kommunikation - Yantit - 21.06.2010 09:50
Ich habe mir jetzt nochmal die Ausgabe mit einem anderen Terminalprogramm (HTERM) angesehen und folgendes festgestellt:
- als erstes kommt das Echo des eingegebenen Befehls, abgeschlossen mit rn
- dann kommt der gesamte Datensatz wie oben schon gezeigt, EBENFALLS abgeschlossen mit rn.
Also hatten alle Recht, die auf die falsche Behandlung des Abschlusszeichens getippt hatten.
Jetzt habe ich mir noch einmal die Hilfe zur Initialisierung der seriellen Schnittstelle durchgelesen: Leider finde ich jetzt keinen Hinweis darauf, wie man der Schnittstelle als Abschlusszeichen BEIDE Werte CR+LF mitgibt.
Kann mir dazu jemand vielleicht noch mal einen Tipp geben?
Pufferüberlauf bei serieller Kommunikation - jg - 21.06.2010 09:59
' schrieb:Jetzt habe ich mir noch einmal die Hilfe zur Initialisierung der seriellen Schnittstelle durchgelesen: Leider finde ich jetzt keinen Hinweis darauf, wie man der Schnittstelle als Abschlusszeichen BEIDE Werte CR+LF mitgibt.Das geht nicht, du kannst bei VISA nur einen "Buchstaben" als Abschlusszeichen angeben.
Kann mir dazu jemand vielleicht noch mal einen Tipp geben?
Aber wo ist das große Problem: Dann nimm LF (also n) als Abschlusszeichen für VISA-Read, und entferne dann bei jedem eingelesenen String das abschließende CR (also r).
Gruß, Jens
Pufferüberlauf bei serieller Kommunikation - Yantit - 21.06.2010 10:02
Das wäre natürlich auch noch ne Idee... Wohl zu einfach, als das man da selbst gleich drauf kommen könnte
Pufferüberlauf bei serieller Kommunikation - Lucki - 21.06.2010 10:12
Das Konfigurations-VI läßts ich bei mir nicht mit
öffnen. Ist dort überhaupt eine genügende Puffergröße konfiguriert? Standard ist glaube ich nur 1k, Du brauchst aber 5k.Das Auslesen der genauen Bytezahl ist ein sehr riskante Sache. Wenn es einmal nicht funktioniert, wird dann auf Immerfort das Ende eine letzten Datensatztes und der Anfang eines neuen Datensatzes gelesen - wie man an Deinem Beispiel sieht. (Der fehlerhafte 0 dBm-Peak markiert die Grenze zwischen beiden Datensätzen)
Falls das Echo zurückgesendet wird, würde ich das Abschlußbyte aktivieren.
Auf die Bytezahl würde ich micht nicht verlassen, besser ist es, die Pause nach dem Senden festzustellen - daran zu erkennen, daß sich die Bytezahl im Puffer nicht mehr erhöht.
Hier ein Vorschlag: (Und bitte "verschönere" das bitte nicht mit überflüssigen Waits und überflüssigen Sequenzrahmen).
[attachment=27260]
(Falls das Echo nicht gesendet wird, entfällt das erste Read-VI)
Pufferüberlauf bei serieller Kommunikation - Yantit - 21.06.2010 10:24
Nochmal ne saublöde Frage: Was ist denn dieses Instr., bei dem Bytes at Port darunter steht? Das ist mir bisher noch nicht untergekommen ?
Pufferüberlauf bei serieller Kommunikation - Lucki - 21.06.2010 10:25
Hast Du überghaupt eine genügende Puffergroße aktiviert? Standard sind glaube ich nur 1k, du brauchst aber 5k.
Du liest immer das Ende eines alten Datensatzes und den Anfang eines neuen. Die Grenze wird markiert durch den fehlerhaften 0 dBm-Peak. Das ist fast unvermeidlich beim Auslesen der genauen Bytezahl - Wenn da mal irgendetwas nicht stimmt, synchronisiert sich das nie wieder von selbst.
Besser ist es, die Pause nach dem Senden zu detektieren, siehe das Beisiel unten. Das erste Read entfällt, wenn das Echo nicht kommt ( Es ist bei den geposteten Daten nicht klar, ob es sich bei der ersten zeile um die Sendeanforderung oder um das Echo handelt)
[attachment=27261]
Bei den geposteten Daten ist übrigens nichts verschoben:
[attachment=27262]
Pufferüberlauf bei serieller Kommunikation - Yantit - 21.06.2010 10:30
In #23 hatte ich ja schon mal beschrieben, wie jetzt wirklich die "Antwort" des Geräts aussieht.
Als Puffergröße hatte ich 512 kByte festgelegt, das sollte ja normalerweise ausreichen...
Pufferüberlauf bei serieller Kommunikation - Lucki - 21.06.2010 14:11
' schrieb:Nochmal ne saublöde Frage: Was ist denn dieses Instr., bei dem Bytes at Port darunter steht? Das ist mir bisher noch nicht untergekommen ?Informationen mit rechte Maustaste/Hilfe. Aber das ist ein vertraulicher Insider-Tipp, bitte nicht weitersagen!