INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

2 fast gleiche Sub-VIs...



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!

07.07.2010, 10:57
Beitrag #1

Yantit Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 160
Registriert seit: Jun 2010

8.2.1
2010
de

63xxx
Deutschland
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ß
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
07.07.2010, 11:34
Beitrag #2

skywalker Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 154
Registriert seit: Jan 2007

2020
2007
DE

99310
Deutschland
2 fast gleiche Sub-VIs...
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
07.07.2010, 11:45
Beitrag #3

Yantit Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 160
Registriert seit: Jun 2010

8.2.1
2010
de

63xxx
Deutschland
2 fast gleiche Sub-VIs...
' 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ß
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
07.07.2010, 11:52
Beitrag #4

IchSelbst Offline
LVF-Guru
*****


Beiträge: 3.695
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
2 fast gleiche Sub-VIs...
' 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.

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
07.07.2010, 12:01
Beitrag #5

Yantit Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 160
Registriert seit: Jun 2010

8.2.1
2010
de

63xxx
Deutschland
2 fast gleiche Sub-VIs...
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ß
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
07.07.2010, 12:22
Beitrag #6

Yantit Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 160
Registriert seit: Jun 2010

8.2.1
2010
de

63xxx
Deutschland
2 fast gleiche Sub-VIs...
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ß
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
30
Antwort schreiben 


Gehe zu: