Natürlich ist kontinuierliches Streamen immer schneller als eine Frage-Antwort-Abarbeitung, gerade per RS-232/VISA. Da hängen unter Windows einige API-Schichten dazwischen, bevor mal wieder von Lesen auf Schreiben umgeschaltet wird.
Dann einige allgemeine Kritikpunkte:
- einmal baust du die beiden Bytes per Plus zusammen, einmal per Join, aber beide Male am Ende in einem Zieldatentyp U8. Meinst du, da passt das im jeden deiner Fälle rein? Bei Plus kannst du einen Überlauf bekommen und beim korrekten Join ist der Zieldatentyp automatisch U16.
- Wozu ein 2D-Array der Größe 4x1000 vorinitialisieren (eigentlich gut), wenn du dann doch wieder per "Insert Into Array" das Array nur vergrößerst?
- Und wo wir schon bei "Insert Into Array" sind, IMHO eine der meist missbrauchten Funktionen in LabVIEW, sie lässt sich fast immer durch ein einfach zu verstehenden "Build Array" ersetzen. Was soll das, mit Initialize Array ein 0x0-Array initialisieren, um dann 4 Werte anzuhängen?
- Sei konsequent und verwende das Vergrößern der Funktion Index Array immer!
Und hier die Verbesserungsvorschläge als VIs:
daq1_2.vi (Größe: 21,42 KB / Downloads: 188)
daq2_2.vi (Größe: 26,48 KB / Downloads: 180)
Die Hauptverbesserung bei Version 2: Wenn du erst einmal die beiden "Trennbytes" erkannt hast, dann musst du das nicht nochmals machen. Ab jetzt einfach immer einen (oder auch mehrere Blocks) aus dem VISA-Buffer auslesen und verarbeiten.
Und geh nochmal zurück ans Zeichenbrett, 100% Fail-Safe ist das mit deinen beiden 0xFF Bytes nicht. Könnte ja sein, dass das erste Zeichen in VISA-Read das zweite 0xFF Byte ist und das erste Low-Byte ebenfalls 0xFF ist. So etwas hatten wir schon.
Gruß, Jens
EDIT: Zum Synch-Problem, hier gab es mal was Ähnliches:
http://www.labviewforum.de/Thread-2Byte-...#pid159774
