(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:
- Verwendung von TermChar, wenn es das Protokoll zulässt. Dann schließt man eine "sehr große" Zahl bei Bytes to Read an.
- Man kennt die Länge der Nachricht. Dann kann man genau diesen Wert bei Bytes to Read anschließen.
- 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
