(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.
