COM-Port: error-cluster

Hallo Beam,

Zitat: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.

Es gibt/gab Gründe, warum ich nach einem konkreten VI von dir gefragt habe.
Jetzt lieferst du genau diesen Grund in deiner Frage - aber immer noch keine Antwort…

Zitat:Diese Warnung läßt sich ja auch nicht auswerten (z.B. mit "Error-Code ungleich 0")

Na klar lässt sich das auswerten - aber eben nicht mit einem einfachen Vergleich mit Null.
Zum Glück kann man ja die Fehlernummer auswerten und entsprechend reagieren!
Schau dir doch mal an, was die Fehlerbehandler intern so alles mit dem Errorcluster anstellen…

Zitat: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.

BytesAtPort gibt an, wieviele Bytes im Empfangsbuffer der seriellen Schnittstelle angekommen sind.
Und das auf jeden Befehl eine andere Anzahl Bytes zurückkommt, ist nicht ungewöhnlich…

Meist benötigt man BytesAtPort aber überhaupt nicht, da man i.A. zwischen zwei Übertragungsarten unterscheiden kann:
1. Die Messages verwenden TermChars, die man dann beim SerialPortInit angeben und aktivieren sollte. Beim VISARead dann einfach mehr Zeichen anfordern als man maximal erwartet.
2. Die Messages verwenden kein TermChar: dann sollte das Protokoll mit festen Messagelängen arbeiten oder die Messagelänge ist in den ersten Bytes der Message hinterlegt. Dann kann man wiederum mit festen zu lesenden Byteanzahlen arbeiten und benötigt auch kein BytesAtPort…

Zitat:Ok, also ist die Fehlerleitung hier völlig witzlos

Nein! Sie garantiert den DATAFLOW!

Zitat: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?

Dass du dein Gerät abfragen kannst, wurde weiter oben schon vorgeschlagen.
Du kannst aber danach in diesem Errorcluster deine eigene Errormeldung hinterlegen, man kann den Cluster ja selbst mit Werten befüllen…

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.

(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

(06.03.2017 10:42 )GerdW schrieb:  Es gibt/gab Gründe, warum ich nach einem konkreten VI von dir gefragt habe.
Jetzt lieferst du genau diesen Grund in deiner Frage - aber immer noch keine Antwort…

Falsch. Es geht immer noch um genau das LabView-Beispiel-VI und zwar unverändert so wie es bei LabView mitgeliefert wurde.
Anstatt obiger überflüssiger Bemerkung (um es mal vorsichtig auszudrücken), sag doch einfach, daß dir nicht bekannt ist, ob es generell bei USB-Geräten anders herum ist oder ob es ev. eine Eigenart der dem Gerät mitgelieferten VI-Treiber ist.

Zitat:Schau dir doch mal an, was die Fehlerbehandler intern so alles mit dem Errorcluster anstellen…

Zitat:BytesAtPort gibt an, wieviele Bytes im Empfangsbuffer der seriellen Schnittstelle angekommen sind.

Soviel hatte ich auch schon heraus bekommen. Aber woher kommt der Wert? Wird der vom Gerät gesendet je nach geschicktem Befehl? Der Wert wird ja offenbar über die Leitung "VISA resource name" mit übertragen, und zwar spätestens nach dem VI "VISA Write"? Oder wie funktioniert das?

Zitat:Meist benötigt man BytesAtPort aber überhaupt nicht,

Hm, und wozu ist er dann in dem LabView-Beispiel-VI drin? Muß doch einen Grund haben?

Zitat: da man i.A. zwischen zwei Übertragungsarten unterscheiden kann:
1. Die Messages verwenden TermChars, die man dann beim SerialPortInit angeben und aktivieren sollte.

Laut der Online-Hilfe ist das per Default aktiviert und auf den Wert "\n" eingestellt?
Habe damit mal etwas herumgespielt. Brachte aber nix. Nur bei den unveränderten Einstellungen kam keine Antwort vom Gerät (und auch keine Fehlermeldung).

Zitat:Nein! Sie garantiert den DATAFLOW!

Das tut doch die Leitung "VISA resource name" schon?
Brauchst mich deswegen nicht gleich anschreien.

(06.03.2017 11:28 )Beam1 schrieb:  

(06.03.2017 10:42 )GerdW schrieb:  Es gibt/gab Gründe, warum ich nach einem konkreten VI von dir gefragt habe.
Jetzt lieferst du genau diesen Grund in deiner Frage - aber immer noch keine Antwort…

Falsch. Es geht immer noch um genau das LabView-Beispiel-VI und zwar unverändert so wie es bei LabView mitgeliefert wurde.
Anstatt obiger überflüssiger Bemerkung (um es mal vorsichtig auszudrücken), sag doch einfach, daß dir nicht bekannt ist, ob es generell bei USB-Geräten anders herum ist oder ob es ev. eine Eigenart der dem Gerät mitgelieferten VI-Treiber ist.

Haben wir diese Frage nicht inzwischen hinreichend beantwortet? Bei USB-Geräten exitiert der abzufragende Port (mglw.) gar nicht. Wählst du eine schon existierende RS-232 Hardware Schnittstelle deines PC aus, dann funktioniert natürlich Open/Read/Write ohne Fehler.

(06.03.2017 11:28 )Beam1 schrieb:  

Zitat:Schau dir doch mal an, was die Fehlerbehandler intern so alles mit dem Errorcluster anstellen…

Zitat:BytesAtPort gibt an, wieviele Bytes im Empfangsbuffer der seriellen Schnittstelle angekommen sind.

Soviel hatte ich auch schon heraus bekommen. Aber woher kommt der Wert? Wird der vom Gerät gesendet je nach geschicktem Befehl? Der Wert wird ja offenbar über die Leitung "VISA resource name" mit übertragen, und zwar spätestens nach dem VI "VISA Write"? Oder wie funktioniert das?

Das habe ich dir schon beantwortet, das kommt aus der Treiber-API!

(06.03.2017 11:28 )Beam1 schrieb:  

Zitat:Meist benötigt man BytesAtPort aber überhaupt nicht,

Hm, und wozu ist er dann in dem LabView-Beispiel-VI drin? Muß doch einen Grund haben?

Frag das NI, nicht jedes Bsp ist 100% sinnvoll. Benötigt wird diese Abfrage bei z.B. Protokollen, bei denen die Nachricht kein festes Abschlusszeichen hat. Es könnte z.B. sein, dass man möglichst schnell Daten aus dem Read-Puffer holen will (ohne Time-Out und Fehlermeldung). Also wird erst ermittelt, wieviele Bytes (mind.) im Puffer sind, um dann genau diese Menge abzuholen.

(06.03.2017 11:28 )Beam1 schrieb:  

Zitat: da man i.A. zwischen zwei Übertragungsarten unterscheiden kann:
1. Die Messages verwenden TermChars, die man dann beim SerialPortInit angeben und aktivieren sollte.

Laut der Online-Hilfe ist das per Default aktiviert und auf den Wert "\n" eingestellt?
Habe damit mal etwas herumgespielt. Brachte aber nix. Nur bei den unveränderten Einstellungen kam keine Antwort vom Gerät (und auch keine Fehlermeldung).

Zitat:Nein! Sie garantiert den DATAFLOW!

Das tut doch die Leitung "VISA resource name" schon?

Dann halt noch, weil es guter LabVIEW-Programmierstil ist... (hatte ich das schon geschrieben? JA).

Gruß, Jens

(06.03.2017 10:56 )jg schrieb:  Jetzt bringst du etwas durcheinander. Nochmal: Frontpanel: Fehler-Boolean grün -> kein Fehler

Ne, eben nicht. Es wird ein rotes Kreuz im Frontpanel angezeigt.

Zitat:-> Wert des Boolean bei "Unbundle" im Blockdiagramm = FALSE;

Ja.

Zitat: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.

Oha, ganz schön kompliziert das ganze.

Zitat:Das kannst du machen, es ist aber kein guter Programmierstil, den Fehlercluster nicht auszuwerten.

Wie soll man denn etwas auswerten, was nicht eindeutig ist ("könnten" weitere Bytes im Puffer sein)? Außerdem will ich ja auswerten, ob ein Gerät angeschlossen ist oder nicht und da habt ihr mir ja jetzt erklärt, daß das nicht geht (Befehl läuft lediglich "ins leere" wenn kein Gerät angeschlossen ist, erzeugt aber keine Fehler- oder Wanrmeldung).

Zitat: Es könnte ja auch keine Antwort gekommen sein, dann erhältst du einen Time-Out Error.

Diesen Error hatte ich lediglich, als ich mal testweise einen höheren "byrtes at port"-Wert getestet hatte, nicht aber wenn keine Antwort vom Gerät kam.

Zitat: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,

Hm, habe ich versucht, geht aber nicht, weil da der Datentyp U32 erwartet wird, d.h. einen negativen Wert kann ich da nicht eingeben.

Zitat: Konfiguriert wird das Abschlußzeichen über das VI "Configure Serial Port".
Vgl. hierzu das LabVIEW-eigene Bsp "Continuous Serial Write and Read.vi"

Das hatte ich mir auch kurz angesehen, aber

(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:Achso, ja klar, der Port existiert ja. Also geht das Schreiben. Bei der Abfrage "Bytes at Port" kommt logischerweise eine 0 zurück,

Für dich ist es vielleicht logisch. :-) Für mich nicht, weil ich die Online-Hilfe so verstanden hatte, daß das die Anzahl der Zeichen ist, die vom Gerät gelesen werden soll. Mir war nicht klar, daß der Wert bereits vom VI "VISA Write" ausgegeben wird.
Ist ja interessant. Also könnte ich doch diesen Wert zur Fehlerbehnadlung auswerten?

---

(06.03.2017 11:51 )jg schrieb:  Haben wir diese Frage nicht inzwischen hinreichend beantwortet? Bei USB-Geräten exitiert der abzufragende Port (mglw.) gar nicht.

Nein, hattet ihr nicht. Wieso existiert bei USB-Geräten der abzufragende Port noch nicht? Die USB-Anschlüsse sind doch genauso im PC fest verbaut wie der COM-Port.

Zitat:Das habe ich dir schon beantwortet, das kommt aus der Treiber-API!

Geht es nicht etwas Anfängergerechter?

Zitat:Frag das NI, nicht jedes Bsp ist 100% sinnvoll.

Na toll. :-( Eigentlich sollte man doch erwarten, daß die Beispiele sinnvoll sind, denn wie soll man als Anfänger sonst lernen, wie sowas gemacht werden muß.

Zitat:Dann halt noch, weil es guter LabVIEW-Programmierstil ist... (hatte ich das schon geschrieben? JA).

Aber du hast nicht geschrieben warum es trotzdem guter Programmierstil ist, wenn die Fehlerleitung gar keine brauchbare Fehlermeldung liefert?
Aber egal, werte ich hierbei eben aus, ob der Antwortstring dem zu erwartenden Antwortstring entspricht.

Anzeige

Zitat:Außerdem will ich ja auswerten, ob ein Gerät angeschlossen ist oder nicht und da habt ihr mir ja jetzt erklärt, daß das nicht geht (Befehl läuft lediglich "ins leere" wenn kein Gerät angeschlossen ist, erzeugt aber keine Fehler- oder Wanrmeldung).

Wenn Du einen Befehl an das Gerät sendest, von dem Du das Ergebnis kennst, z.B. "init" kannst Du doch selbst entscheiden. Gerät antwortet richtig also ist da oder Gerät antwortet mit falschem Text, dass ist ein anderes Gerät oder keine Antwort nach beliebigem Timeout kein Gerät angeschlossen.

Zitat:Für dich ist es vielleicht logisch. :-) Für mich nicht, weil ich die Online-Hilfe so verstanden hatte, daß das die Anzahl der Zeichen ist, die vom Gerät gelesen werden soll. Mir war nicht klar, daß der Wert bereits vom VI "VISA Write" ausgegeben wird.
Ist ja interessant. Also könnte ich doch diesen Wert zur Fehlerbehnadlung auswerten?

"Bytes at Port" gibt die Meng an, die gelesen werden kann. Nicht die ich lesen will.
Die ich lesen will trage ich bei dem Befehl read ein.

Zitat:Mir war nicht klar, daß der Wert bereits vom VI "VISA Write" ausgegeben wird.

Vertausche nicht die Funktionen, der Write Befehl definiert nicht die Menge der eingehenden Bytes. Das würde auch keinen Sinn machen.

Gruß
Freddy

(06.03.2017 12:12 )Beam1 schrieb:  Ne, eben nicht. Es wird ein rotes Kreuz im Frontpanel angezeigt.

Dann lad mal bitte das entsprechende VI hoch. Das ist dann nicht mehr der Standard-Errorcluster, da hat jemand dran "rumgepfuscht". Standardmäßig bedeutet das rote X im Frontpanel "Fehler". Wichtig ist jedoch (eigentlich) nur, was der Wert des Boolean nach Unbundle ist. TRUE=Fehler.

(06.03.2017 12:12 )Beam1 schrieb:  Oha, ganz schön kompliziert das ganze.

Das ist Standard bei vielen APIs. TCP/IP, DAQmx, usw. usw.; Der Treiber erledigt tief untern die Hardware-Geschichten, die Software-API sind häufig asynchron.

(06.03.2017 12:12 )Beam1 schrieb:  Wie soll man denn etwas auswerten, was nicht eindeutig ist ("könnten" weitere Bytes im Puffer sein)? Außerdem will ich ja auswerten, ob ein Gerät angeschlossen ist oder nicht und da habt ihr mir ja jetzt erklärt, daß das nicht geht (Befehl läuft lediglich "ins leere" wenn kein Gerät angeschlossen ist, erzeugt aber keine Fehler- oder Wanrmeldung).

Dann hast du uns noch nicht verstanden. Am Ende musst bzw. solltest du alles auswerten. Punkt 1 ist, liefert VISA Write schon einen Fehler, weil der ausgewählte COM-Port nicht existiert. Punkt 2 ist ein möglicher Time-Out und/oder die Antwort bei VISA-Read, weil kein Gerät bzw. ein anderes am RS-232 angeschlossen ist.

(06.03.2017 12:12 )Beam1 schrieb:  

Zitat: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,

Hm, habe ich versucht, geht aber nicht, weil da der Datentyp U32 erwartet wird, d.h. einen negativen Wert kann ich da nicht eingeben.

Entschuldige, da hab ich Müll erzählt. Bei fast allen anderen APIs geht das mit einem -1, dann wird einem der gesamte Buffer zurückgegeben. Bei VISA gibt es sinnvolle 3 Möglichkeiten:

1. Verwendung von TermChar, wenn es das Protokoll zulässt. Dann schließt man eine "sehr große" Zahl bei Bytes to Read an.
2. Man kennt die Länge der Nachricht. Dann kann man genau diesen Wert bei Bytes to Read anschließen.
3. Man braucht es variabel, dann wird oft mit dem Verfahren "Bytes at Port" so wie in dem Bsp gearbeitet.
   

Alle Varianten haben ihren Sinn und ihre Berechtigung. Wenn du dich länger mit Programmierung beschäftigst, dann wirst du das auch irgendwann erkennen.

(06.03.2017 12:12 )Beam1 schrieb:  

Zitat:Achso, ja klar, der Port existiert ja. Also geht das Schreiben. Bei der Abfrage "Bytes at Port" kommt logischerweise eine 0 zurück,

Für dich ist es vielleicht logisch. :-) Für mich nicht, weil ich die Online-Hilfe so verstanden hatte, daß das die Anzahl der Zeichen ist, die vom Gerät gelesen werden soll. Mir war nicht klar, daß der Wert bereits vom VI "VISA Write" ausgegeben wird.

Wie Freddy schon geschrieben hat, der kommt nicht aus "VISA Write", sondern aus der VISA-Treiber-API. Die Hardware-API empfängt die Zeichen am RS-232-Port und schiebt sie in einen FIFO-Puffer. Mit diesem Eigenschaftsknoten wird ausgewertet, wie groß dieser FIFO zum Zeitpunkt der Abfrage ist.

(06.03.2017 12:12 )Beam1 schrieb:  Ist ja interessant. Also könnte ich doch diesen Wert zur Fehlerbehnadlung auswerten?

Ja, das kannst du. Wenn nach gewisser Zeit der Buffer immer noch 0 ist, dann hat offenbar kein Gerät geantwortet.

(06.03.2017 12:12 )Beam1 schrieb:  

(06.03.2017 11:51 )jg schrieb:  Haben wir diese Frage nicht inzwischen hinreichend beantwortet? Bei USB-Geräten exitiert der abzufragende Port (mglw.) gar nicht.

Nein, hattet ihr nicht. Wieso existiert bei USB-Geräten der abzufragende Port noch nicht? Die USB-Anschlüsse sind doch genauso im PC fest verbaut wie der COM-Port.

Der USB-Port mag existieren, aber nicht der durch das Einstecken des USB-Gerätes per Treiber erzeugte virtuelle COM-Port! (Das ist zumindest eine Standard-Variante, um USB-Geräte mit einem seriellen Protokoll an Computer anzuschließen.)

(06.03.2017 11:51 )jg schrieb:  

Zitat:Dann halt noch, weil es guter LabVIEW-Programmierstil ist... (hatte ich das schon geschrieben? JA).

Aber du hast nicht geschrieben warum es trotzdem guter Programmierstil ist, wenn die Fehlerleitung gar keine brauchbare Fehlermeldung liefert?
Aber egal, werte ich hierbei eben aus, ob der Antwortstring dem zu erwartenden Antwortstring entspricht.

Viele VIs und Funktionen (ich muss zugeben, leider nicht alle) haben einen Error-In und einen Error-Out. Das Durchverbinden des Error-Cluster ist somit die einfachste Möglichkeit, eine Abarbeitungsreihenfolge von Funktionen/VIs zu programmieren. Häufig führt ein vorliegender Fehler an einem Error-In auch dazu, dass das entsprechende VI erst gar nicht abgearbeitet wird. Es liegt ja ein mglw. schwerwiegender Fehler vor, also so schnell wie möglich weitermachen, bis das Programm an eine Stelle kommt, wo auf den Fehler reagiert wird und das System z.B. in einen sicheren Zustand versetzt wird.
Weiterhin gibt es eine für den Anfänger (vielleicht nützliche) Standard-Einstellung der LabVIEW Umgebung und von neuen VIs, nämlich dass ein Fehler-Ausgang, der nicht irgendwie ausgewertet wird, automatisch einen Fehler-Dialog erzeugt, und (u.a.) genau deshalb sind nicht ausgewertete Error-Out schlechter Programmierstil in LabVIEW.

Gruß, Jens