(06.03.2017 10:29 )Beam1 schrieb: Hallo, Freddy,
Endlich mal einer, der eine gut hilfreiche Antwort gibt. Danke.
(01.03.2017 10:06 )Freddy schrieb: Der Fehler Cluster Zeigt bei einem Fehler wie GerdW schon schrieb immer rot für Fehler und grün für kein Fehler. Aber true im Fehler Cluster bedeutet ein Fehler gefunden. Das hat mich am Anfang auch immer etwas irritiert. Schließlich ist true immer "Gut" und false immer "Schlecht" aber es kommt dabei auf die Fragestellung an und der Fehler Cluster ist eben aktive (true) wenn ein Fehler auftritt.
Ja, sehr verwirrend. Bei einem Gerät, was ich am USB-Port hängen habe, ist es nämlich genau anders herum. Da zeigt der Fehler-Cluster beim Fehler ein rotes Kreuz und bei "no error" ein grünes Häkchen. Ich weiß aber nicht, ob das eine Eigenart der mitgeliefeten LabView-Treiber ist oder ob es bei USB-Geräten generell anders ist.
Jetzt bringst du etwas durcheinander. Nochmal: Frontpanel: Fehler-Boolean grün -> kein Fehler -> Wert des Boolean bei "
Unbundle" im Blockdiagramm = FALSE;
Fehler-Boolean rot -> Fehler -> Wert des Boolean bei Unbundle im Block Diagramm = TRUE
(01.03.2017 10:06 )Freddy schrieb: Zitat:Wenn Du eine COM Schnittstelle verwendest, die auf dem Rechner vorhanden ist aber nicht angeschlossen. Kann man diese initialisieren(sie ist ja da). Man kann was schreiben, denn es werden bei dem Beispiel in der Initialisierung die Handshake - Steuerung abgeschaltet. Also schreibt das System in eine offene Leitung daher kein Fehler.
Die Bytes Abfrage ist bei "keinem Byt vorhanden" auch ok. Daher auch hier kein Fehler.
Aha. Das war mir nicht bekannt.
Zitat:Beim lesen kommt eine Warnung weil nichts zu lesen ansteht.
Und warum nur eine Warnung und nicht ein Fehler? Ich finde das ziemlich unlogisch.
Diese Warnung läßt sich ja auch nicht auswerten (z.B. mit "Error-Code ungleich 0"), weil beim "VISA Read" immer eine Warnung ausgegen wird (mit zwei verschiedenen Geräten und unterschiedlichen Befehlen getestet), und zwar immer wegen "VISA: (Hex 0x3FFF0006) The number of bytes transferred is equal to the requested input count. More data might be available." Das stimmt aber nicht. Es werden alle Daten korrekt gelesen und im Response-Feld angezeigt. Ich habe testweise mal versucht, "bytes cout" per Konstante an das VI "VISA Read" zu übergeben und den Wert schrittweise zu erhöhen. Es werden aber keine weiteren Zeichen gelesen, im Gegenteil, es kommt dann ein Timeout. Also ist der Wert, den dieses "Bytes at Port" liefert, korrekt. Woher dieser Wert allerdings stammt, ist mir unklar. Ich kann nur erkennen, daß dieser je nach zuvor gesendeten Befehl dynamisch angepaßt wird.
Durch die VISA-Treiber Schicht arbeitest du quasi asynchron. Der Treiber "tief unten" im System übernimmt das Lesen und Schreiben und übergibt beim Lesen die Werte an die API (in diesem Fall dein VISA-Read). Jetzt könnte Folgendes passieren: Du fragst per PropertyNode das "Bytes at Port" ab. Rückgabe z.B. 10. Windows spukt dir dazwischen und es wird nicht gleich VISA-Read ausgeführt. Der Lesepuffer des Treibers empfängt währenddessen weitere Zeichen. Wenn jetzt VISA-Read bei dir im Programm ausgeführt wird, dann werden dir die angeforderten 10 Zeichen zurückgegeben. LabVIEW weist dich aber mit einer Warnung darauf hin, dass es weitere Elemente im Puffer geben
könnte. Inwieweit du diese Warnung jetzt weiter verwendest, das musst du selber entscheiden.
(06.03.2017 10:29 )Beam1 schrieb: Zitat:Die Auswertung der "*IDN?" machen die VI für die serielle Schnittstelle nicht, dass musst Du selber machen.
Ok, also ist die Fehlerleitung hier völlig witzlos und ich muß mir was anderes ausdenken. Es geht ja um den Anschluß eines ganz bestimmten Gerätes. Also könnte ich nach "*IDN?" fragen und wenn dann nicht der für das Gerät korrekte Antwortstring kommt, lasse ich eine individuelle Fehlermeldung ausgeben ohne die Fehlerleitung und einen Fehler-Cluster zu nutzen?
Das kannst du machen, es ist aber kein guter Programmierstil, den Fehlercluster nicht auszuwerten. Es könnte ja auch keine Antwort gekommen sein, dann erhältst du einen Time-Out Error. Zusätzlich solltest du natürlich (wenn eine Antwort kommt) diese auch auswerten.
Wenn du übrigens ein Geräte-Protokoll verwendest, welches Nachrichten immer mit einem bestimmten Zeichen abschließt ( z.B. Newline=0x0A=\n ), so wie in dem Beispiel, macht es Sinn, auf das Bytes at Port zu verzichten. Stattdessen schließt du ein -1 am Byte-Count-Eingang von VISA-Read an, VISA-Read liest dann solange aus dem "Treiber-Puffer", bis es das Abschlußzeichen im Datenstream findet und gibt dir genau 1 komplette Nachricht zurück. Sehr elegant. Konfiguriert wird das Abschlußzeichen über das VI "Configure Serial Port".
Vgl. hierzu das LabVIEW-eigene Bsp "Continuous Serial Write and Read.vi"
Gruß, Jens
(06.03.2017 10:42 )Beam1 schrieb: Hallo
(28.02.2017 17:05 )jg schrieb: Hast du dir einmal die Mühe gemacht, in das VI "VISA Configure Serial Port (Instr).vi" hineinzuschauen?
Aus Neugierde, ja. aber 
Bringt mir als Anfänger also nix. Und leider ist bei den Beispielen ja auch nicht beschrieben, was da im Detail passiert und warum man dies und jenes im Blockdiagramm genau so macht und warum. Und auch die Context-Hilfe (gerade auch bei "Detailed Help") setzt da zu viel an Grundwissen vorraus, bringt also für diese Detailfragen genau nix für Anfänger.
Zitat: Übrigens, wenn gar kein Gerät angeschlossen ist, der COM-Port aber existiert, dann wirst du auf jeden Fall erst einen Fehler erhalten, wenn du auf eine Antwort auf irgendeine Anfrage wartest.
Aber hier kommt auch keine Fehlermeldung, sondern nur eine Warnung und der Fehlercode der Warnung bezieht sich auch nicht auf "keine Antwort", sondern auf "VISA: (Hex 0x3FFF0006) The number of bytes transferred is equal to the requested input count. More data might be available.". Und genau die gleiche Warnung kommt auch, wenn das Gerät angeschlossen ist und korrekt funktioniert und obwohl die Antwort dann vollständig erhalten wurde. Reichlich verwirrend das ganze.
Achso, ja klar, der Port existiert ja. Also geht das Schreiben. Bei der Abfrage "Bytes at Port" kommt logischerweise eine 0 zurück, es ist ja kein Gerät angeschlossen, welches dir antworten könnte (oder es ist ein Gerät verbunden, welches deine Anfrage nicht versteht und deshalb nicht antwortet). Du forderst also 0 Byte aus dem Datenpuffer an, das kann natürlich immer ausgeführt werden. Antwort ist ein leerer String mit der Warnung, dass es mehr Bytes geben könnte.
Gruß, Jens
