Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
18.06.2010, 10:10 (Dieser Beitrag wurde zuletzt bearbeitet: 18.06.2010 10:12 von GerdW.)
- du leerst immer noch den Transmit-Buffer, ist das Absicht?
- du fragst immer noch nicht ab, wieviele Bytes du eigentlich empfängst
- du hast nicht wirklich die Aufräumfunktion verwendet (die hinterlässt keine verdeckten Drähte und weniger Knicke in den Drähten)
- immer noch CoercionDots...
Prüfe bitte, wie lang die Antwort des Analyzers auf deine Anfrage ist!
Edit:
"5000 Bytes lese ich aus, weil ca. 4600 Bytes pro Sendeanforderung auflaufen (wurde vorher geprüft)."
D.h. dein VISA-Read liefert entweder einen TimeOut-Fehler oder (eher unwahrscheinlich) den Anfang der nächsten Antwort mit?
- du leerst immer noch den Transmit-Buffer, ist das Absicht?
- du fragst immer noch nicht ab, wieviele Bytes du eigentlich empfängst
- du hast nicht wirklich die Aufräumfunktion verwendet (die hinterlässt keine verdeckten Drähte und weniger Knicke in den Drähten)
- immer noch CoercionDots...
Prüfe bitte, wie lang die Antwort des Analyzers auf deine Anfrage ist!
Edit:
"5000 Bytes lese ich aus, weil ca. 4600 Bytes pro Sendeanforderung auflaufen (wurde vorher geprüft)."
D.h. dein VISA-Read liefert entweder einen TimeOut-Fehler oder (eher unwahrscheinlich) den Anfang der nächsten Antwort mit?
Ich habe jetzt noch einmal versucht, den Empfangspuffer (Maskenwert 16 od. 64) zu leeren, allerdings bekomme ich dann keine Messwerte mehr ausgegeben.
Ich habe noch einmal geschaut, ich empfange genau 4413 Byte, die ich jetzt auch Visa-Read als Parameter zur Verfügung stelle.
Aufräumfunktion habe ich nun auch benutzt, allerdings erst, nachdem ich das Snippet hochgeladen habe.
Was sind Coercion Dots???
EDIT:
Hier die "aufgeräumte" Version, so wie sie LabVIEW mir liefert...
18.06.2010, 10:40 (Dieser Beitrag wurde zuletzt bearbeitet: 18.06.2010 10:42 von GerdW.)
Das sind die roten Punkte an den Eingängen von: VISA-Read, Delay, "Größe Messwert Array..", VISA Flush. Die zeigen, dass LabVIEW eine Typumwandlung vornehmen muss, z.B. von I32 auf U32 (Delay) oder I32 auf DBL (Indicator). Diese CoercionDots treten nicht auf, wenn man die Konstanten per Rechtsklick->Create... erzeugt, da dann automatisch der korrekte Datentyp verwendet wird. In LabVIEW macht man viel mit dem Rechtsklick, hat durchaus Vorteile! Edit:zweites Ergebnis in der LabVIEW-Onlinehilfe...
"allerdings bekomme ich dann keine Messwerte mehr ausgegeben."
Fehlermeldung?
"allerdings bekomme ich dann keine Messwerte mehr ausgegeben."
Fehlermeldung?
Gar keine! Es zeigt mir nur an, dass permanent dann nur 22 Bytes gelesen werden (das ist wohl der Text "trac:data? trace1", den ich zum Abfragen der Messwerte an das gerät schicke und der mir dann wieder angezeigt wird als "Ausgabe"; daher 'filtere' ich diesen Text mit der Case-Anweisung aus)...
was ist denn das für ein Messgerät, das mit dem Messbefehl antwortet?
Oder liegt das an einer schlechten Schnittstellenkonfiguration (irgendwo ein "Echo" aktiviert?)?
was ist denn das für ein Messgerät, das mit dem Messbefehl antwortet?
Oder liegt das an einer schlechten Schnittstellenkonfiguration (irgendwo ein "Echo" aktiviert?)?
Ist ein Remote-Spektrumanalyzer, der mit normalen ASCII-Befehlen "beschrieben" wird und dann über die serielle Schnittstelle die Antwort zurückliefert. Konfigurationen für die Schnittstelle sind wohl nicht vorhanden, zumindest ist mir in keinem Manual davon irgendetwas begegnet...
18.06.2010, 12:58 (Dieser Beitrag wurde zuletzt bearbeitet: 18.06.2010 12:58 von GerdW.)
wenn du die serielle Schnittstelle benutzt, kannst du die komplette Kommunikation mittels Hyperterminal testen. Wenn es dort läuft, läuft's auch mit LabVIEW!
Anbei dein VI etwas modifiziert und kommentiert... ()
wenn du die serielle Schnittstelle benutzt, kannst du die komplette Kommunikation mittels Hyperterminal testen. Wenn es dort läuft, läuft's auch mit LabVIEW!
Anbei dein VI etwas modifiziert und kommentiert... ()
Hallo!
Ich habe gerade mal mein VI nach deinen Vorgaben umgebaut und die Tipps beherzigt. Leider läuft das Ding immer noch nicht so, wie ich es gerne hätte. Verwende ich dein Verfahren zur Abfrage der Messwerte, dann liefert er mir keinen Graphen bzw. es kommen keine Messwerte bei mir an. Die restlichen Modifikationen (Konstanten außerhalb der Schleife, etc.) habe ich bei mir eingepflegt und damit läuft es auch alles rund, nur das Problem mit dem Pufferüberlauf bleibt weiterhin bestehen.
Langsam frage ich mich echt, woran das denn jetzt konkret liegen könnte...
Bin leider ratlos!
Gruß
21.06.2010, 08:02 (Dieser Beitrag wurde zuletzt bearbeitet: 21.06.2010 08:25 von rolfk.)
' schrieb:Langsam frage ich mich echt, woran das denn jetzt konkret liegen könnte...
Ziemlich spät, meiner bescheidenen Meinung nach!
Wie schon anderswo angesprochen ist es wirklich fraglich ob das Gerät so antwortet wie Du es Dir vorstellst. Zurst mal die Tatsache dass das Gerät kein Endezeichen zu haben scheint. Da Du zu Beginn 5000 Bytes lesen wolltest aber nur 4400 und etwas rein kam hättest Du da jeweils ein Timeoutfehler kriegen müssen. Da das scheinbar nicht reinkam, müsste doch irgendwie ein Endezeichen sein. Auch zeigst Du die Initialisierung der Schnittstelle nicht, so dass man nicht sieht ob Du die Endezeichenkonfiguration wirklich ausschaltest (die ist bei Serial VISA Default eingeschaltet und auf Line Feed eingestellt). Und Dein Filterstring hat ja eindeutig ein rn am Ende und das ist anders dann der n den Du schickst, also ist die Aussage dass das Gerät kein Endezeichen zurücksendet schlichtweg falsch! Tut es eben schon und scheinbar sendet es jedes Kommand als Echo zurück und danach die eigentlichen Daten als seperate Zeile.
Der einzige mir logische erscheinende Grund dass Du einen Bufferüberlauf bekommst, wäre dass das Instrument nicht einfach antwortet wenn es ein Kommando bekommt sondern konstant Datentelegramme ausspuckt. Dein VISA Read liest dann jeweils ein solches Telegramm und wartet danach 500 ms bevor es die nächste Loop startet. In der Zwischenzeit spuckt Dein Gerät weitere Telegramme aus und beim nächsten Schlaufendurchlauf liest Du dann das nächste Telegramm ein, was inzwischen schon alt ist.
Das grosse Rätsel ist noch warum das Flush Buffer in Deinem Post #12 diesen Umstand nicht verhindert. Hast Du schon mal versucht mit dem Wert 16 statt 64?
Und zu guter Letzt: Der Error Cluster ist nicht nur zum Spass vorhanden. Zu einer guten Gerätekommunikation gehort auch Fehlerbehandlung. Du solltest den Error Cluster zumindest durch alle VISA Funktionen durchschlaufen und am Ende auf dem Frontpanel darstellen. Dann bekommst Du zumindest eine Idee wenn etwas falsch geht. Ein guter Treiber zeigt aber nicht nur alle Fehler an sondern versucht auch an geeigneten Stellen bestimmte Fehler zu erkennen und ein Retry oder andere geeignete Massnahmen zu treffen um den Fehler zu beheben.
Notiz: Dass Du zu Beginn einen Bufferüberlauf bekamst ist gar nicht verwunderlich. Du sendest ein Kommando und das Gerät antwortet mit zwei Zeilen: Die erste ist das Echo des Kommandos und die zweite ist der Datenstring. Aber Du liest immer nur eine Zeile pro Schlaufe aus (da Du die Endezeichenbehandlung von VISA mit 99.9999% Sicherheit eben nicht ausgeschaltet hast. Also sendest Du in jeder Schlaufe ein Kommando und liest nur in jedem zweiten Durchgang die eigentlichen Daten. Dass da einiges and Daten ansammelt im Laufe der Zeit sollte ja logisch sein. Und jetzt bitte nicht die Endezeichenbehandlung von VISA ausschalten, das wäre wirklich das Pferd am Schwanz aufzäumen. Anstelle davon machst Du am Anfang (vor der Schalufe ein Flush mit 196 um beide Buffer komplett zu leeren) und danach in der Schlaufe erst ein VISA Read mit etwa 100 als Characters to Read um das Kommandoecho zu lesen und wenn Du das Echo des Kommandos detektierst (Dein Gleichzeichen mit dem String) noch einmal ein VISA Read, aber diesmal mit 5000 Charactern und das sind Deine Daten und wenn das Kommandoecho nicht stimmst machst Du ein Flush im anderen Case.
' schrieb:Langsam frage ich mich echt, woran das denn jetzt konkret liegen könnte...
Vielleicht liegt es an der Schnittstellenkonfiguration, die Du uns hier vorenthälst. Z.B führt es direkt in die Katastrophe, wenn das Abschlußzeichen noch aktiviert ist - und standardmäßig ist das der Fall. Es könnte auch sinnvoll sein, einen typischen Antwortstring mal zu posten bzw. über das Format dieses Strings überhaupt mal etwas zu sagen.
Was ich fast nicht glauben kann: Das Format der Sendeanforderung ist mit Abschlußzeichen "n". Und die Antwort soll aber dann ohne Abschlußzeichen sein? So etwas macht man doch in der Regel beidseitig.
Das Löschen von Daten durch Leeren des Puffers, ohne überhaupt zu wissen warum es zum Überhlauf kam, löst doch allenfalls das Problem, indem es ein anderes schafft.
Edit: ich bin leider langsam. Als ich das Posting erstellte, war Rolfk's Antwort noch nicht da..
Bemerkung zum Thema Errorcluster: Ohne angeschlossenen Errorcluster kommt es Zum Stop des Programms bei Error - und Timeout ist ein Error. Beim ersten geposteten VI ganz oben wurden 5000 Bytes erwartet, obwohl der String kürzer war. Es hätte also zum Timoutfehler kommen müssen. Daß es nicht dazu kam, ist schon fast der Beweis, daß TermChar nicht deaktiviert wurde und der String immer nur unvollständig gelesen wurde.
/
Pufferüberlauf bei serieller Kommunikation
)
