2 fast gleiche Sub-VIs...

Hallo!

Ich bin gerade schwer am rätseln, wieso ein Sub-VI von mir funktioniert, und das andere, dass genau gleich aufgebaut ist, bis auf das es einen anderen ASCII-Befehl an ein Gerät schickt, nicht?

   

Dieses VI funktioniert nicht. Es kommt nur ein leerer String als Ausgabe.

   

Dieses VI funktioniert, es liefert einen String in folgender Form (vor dem whitespacetrim): :freq:span? rn 10.000 MHz rn

   

Das ist der Kontext im Haupt-VI, in dem beide laufen. Entweder bin ich zu blöd oder schon zu betriebsblind, zumindest sehe ich keinen Unterschied innerhalb der VIs, der einen Fehler bewirken könnte.

Kann mir jemand helfen?

Gruß

Anzeige

Was soll die for-Schleife bewirken? Versteh den Sinn nicht ganz.

Du wartest 400 ms und liest die Daten zwei mal auf der seriellen Schnittstelle aus. Sind beim zweiten auslesen keine Daten mehr vorhanden, so bekommst du einen leeren String.

' schrieb:Was soll die for-Schleife bewirken? Versteh den Sinn nicht ganz.

Damit lese ich zuerst das Echo des gesendeten Befehls aus (ist ja mit /r abgeschlossen, auch als Abbruchbedingung definiert) und im nächsten Durchlauf lese ich die eigentliche Antwort aus. Das Verfahren funktioniert auch prima (wird ja mehrfach so in meinem Programm eingesetzt, weiterhin läuft es ja im zweiten VI genauso und funktioniert.

Gruß

' schrieb:Damit lese ich zuerst das Echo des gesendeten Befehls aus (ist ja mit /r abgeschlossen, auch als Abbruchbedingung definiert) und im nächsten Durchlauf lese ich die eigentliche Antwort aus. Das Verfahren funktioniert auch prima (wird ja mehrfach so in meinem Programm eingesetzt, weiterhin läuft es ja im zweiten VI genauso und funktioniert.

Das Verfahren ist aber inkonsequent. Entweder lese ich eine bestimmte Anzahl von Zeichen ein oder aber alles bin zum Endezeichen. Ein Mischen dieser beiden Möglichkeiten führt zwangsläufig zu problematischen Situationen - von denen ja jetzt eine aufgetreten ist.

Wenn der Puffer leer ist, lesen eben beide Forschleifendurchläufe nix ein. Die Elemente sollen ja schließlich nur eine bestimmte Anzahl Zeichen einlesen.

Du solltest wie folgt vorgehen: Daten senden an Endgerät - Warten, bis die erwartete Anzahl Zeichen im Puffer steht - Dann Auslesen bis Endezeichen und nochmals auslesen bis Endezeichen und zwar jeweils ohne Anschluss einer festen Anzahl.

Zitat:Wenn der Puffer leer ist, lesen eben beide Forschleifendurchläufe nix ein. Die Elemente sollen ja schließlich nur eine bestimmte Anzahl Zeichen einlesen.

Ok, klar, das leuchtet mir ein.

Zitat:Du solltest wie folgt vorgehen: Daten senden an Endgerät - Warten, bis die erwartete Anzahl Zeichen im Puffer steht - Dann Auslesen bis Endezeichen und nochmals auslesen bis Endezeichen und zwar jeweils ohne Anschluss einer festen Anzahl.

Das wiederum nicht. LV fordert ja von mir den Anschluss einer Anzahl von Bytes (ich habe es in meinem Sub-VI sowohl mit der mir bekannten maximalen Anzahl an Bytes [32] und, wie zu sehen, mit Bytes at port.

Nach meinem Verständnis ist es doch so: Visa read liest die angegebe Anzahl von Bytes aus einem "Puffer" ein. Wenn in diesem Puffer/Zeichenkette, etc. ein vorher bei der Initialisierung der COM-Schnittstelle definiertes Abschlusszeichen (n, r, o. ä.) auftaucht, und die Zahl der Bytes zum lesen kleiner ist als die gelesenen, so kommt doch normalerweise nur eine Warnung, dass möglicherweise noch Zeichen im Puffer liegen.

Wie wäre denn nun die sauberste Lösung? Mittlerweile traue ich der Sache ja nicht mehr, obwohl sie seit ca. 4 Wochen funktioniert hat (das hier ist ein Umbau auf eine fernbedienbare Variante des ursprünglichen Programms).

Gruß

Kann geschlossen werden. Hatte nicht bedacht, dass das Gerät schon bei der Initialisierung eine Ausgabe produziert. Ein "Puffer leeren" vor dem ersten Sub-VI bringt die Lösung...

Danke für die Mühe...

Gruß