Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Vielen Stammnutzern dürfte meine Problemstellung mittlerweile bekannt sein (hab ja auch schon oft genug genervt und rumgefragt
Zu meinem "Problem":
Ich habe mein Programm zum Auslesen von Messwerten aus einem Spektrumanalyzer jetzt fertig gestellt und bin auch mit der Sache recht zufrieden.
Das einzige, was mich im Moment noch stört ist die Tatsache, dass die Messwerte relativ langsam auf dem Analyzer darstellt werden. Das Auslesen und anzeigen sollte/könnte vielleicht noch etwas schneller vonstatten gehen.
Leider weiß ich nicht, ob man an dem bestehenden Code noch etwas optimieren kann oder ob es schlicht und ergreifend am Lösungsansatz selbst liegt.
Vielleicht hat jemand mal Zeit und Lust, sich mein VI zu betrachten und seine Meinung zu äußern.
Grundsätzlich geht es nur um die "hintere" while-Schleife, die Initialisierung und Wertübernahme reicht vollkommen aus von der Geschwindigkeit, da besteht keine Notwendigkeit für Optimierung...
du weißt schon, dass allein die Übertragung von 4500 Bytes über eine serielle Schnittstelle mit 115200 baud ca. 0.4s benötigt?
Wie "langsam" ist denn die Schleife?
du weißt schon, dass allein die Übertragung von 4500 Bytes über eine serielle Schnittstelle mit 115200 baud ca. 0.4s benötigt?
Wie "langsam" ist denn die Schleife?
Ja, die ca. 0,3 s sind mir bekannt, das wäre auch ein Wert, mit dem ich sehr gut leben könnte (ca. 2 Aktualisierungen/s). Aber momentan sind das ca. 2 s/Ausführung/Aktualisierung.
Als ich es das erste Mal (falsch) programmiert hatte, ging die Sache wesentlich flotter vonstatten. Nur kann ich mir nicht vorstellen, dass der Vergleich der beiden Strings, die Case-Entscheidung und das Umwandeln von 402 Punkten in ein Array mit anschließender Darstellung in einem Graphen wirklich so lange dauern kann (kann aber auch sein, dass ich mich täusche, meine letzten textbasierten Programmiererfahrungen liegen 5 Jahre zurück...)
EDIT: Teilweise hat die Schleife gelegentlich mal einen Hänger, da wartet man so 5 - 7 sec. auf eine Aktualisierung...
noch'ne Idee:
Momentan bombardierst du deinen Analyzer mit Trace-Anfragen. Wenn eine Abfrage nicht erfolgreich war, erfolgt sofort die nächste...
Was passiert, wenn du eine kleine Wartezeit (20ms?) in die Schleife mit hineinnimmst (z.B. im FALSE-Case)?
Antwortet der Analyzer überhaupt so schnell oder braucht der immer erst etwas Zeit, um den Trace aufzunehmen?
noch'ne Idee:
Momentan bombardierst du deinen Analyzer mit Trace-Anfragen. Wenn eine Abfrage nicht erfolgreich war, erfolgt sofort die nächste...
Was passiert, wenn du eine kleine Wartezeit (20ms?) in die Schleife mit hineinnimmst (z.B. im FALSE-Case)?
Antwortet der Analyzer überhaupt so schnell oder braucht der immer erst etwas Zeit, um den Trace aufzunehmen?
Hatte ich schon mal probiert, hilft allerdings nichts. Zumal ich noch dazu erwähnen muss, dass es vom Hersteller ein Programm zur Ansteuerung des Analyzers gibt, das ebenfalls in LV programmiert ist. Dieses kann die Daten auch ausreichend schnell auslesen. Daher gehe ich stark davon aus, dass der "Fehler" innerhalb meines Programmes liegt. Das Gerät kommt wohl auch mit häufigen Abfragen zurecht...
wie macht es denn der Hersteller in seinem Programm?
Das weiß ich leider nicht: es ist eine kompilierte exe-Datei und wenn ich die mit LV öffne (LLB-Manager) und auf einen VI-Eintrag klicke, erhalte ich die Meldung:
"LabVIEW-Ladefehlercode 11: Die vorhandene LV-Version (7.1) kann nicht in die aktuelle Version (9.0) umgewandelt werden, da das VI kein Blockdiagramm hat".
Ich sehe da keine wesentliche Optimierungsmöglichkeit mehr. Wenn der Hersteller es in seinem Programm schneller hinbekommen hat, dann gibt es vielleicht noch Konfigurationsmöglichkeiten am Analyser, die Du nicht ausgereizt hast. Z.B. dieses 100000malige Anhängen von "dBm" an jede Zahl, bekommt man das nicht weg? Oder wenn die Schnittstelle ein virtueller USB - COMport ist, dann gibt vielleicht noch höhere Baudraten als 115000?
Außerdem: Mit eingefügten Uhren ins Programm ist es doch kein Problem, die Reaktionszeit des Grerätes mal zu messen.
Ich glaube, ich habe jetzt zumindest die Ursache der "Langsamkeit" ein wenig eingrenzen können: Und zwar scheint das Problem in dem letzten Read vor dem Vergleich mit dem String zu liegen. Wenn das Programm ein bisschen läuft, wirft dieses Read einen Fehler raus, dass weniger Daten als angefordert gelesen wurden. Daraufhin läuft die ganze Sache in den Timeout (5 s) rein und läuft dann erst weiter.
Dann geht es einige Zyklen lang gut, bevor das Spiel wieder passiert. Somit kommt wohl die Langsamkeit insgesamt zustande.
Ich habe es jetzt schon mal mit Bytes at Port versucht, aber das bringt mir auch nicht das gewünschte Ergebnis.
Bin dabei mir das mal anzuschauen, aber einen Fehler gleich mal vorweg:
Wenn das Gerät als Abschlußzeichen "rn" sendet, dann muß das Abschlußzeichen für die serielle Schnittstelle natürlich das letzte Zeichen sein, also n = xA und nicht r = xD. Denn andernfalls bleiben bei jeder Übrtragung 2*1 Zeichen im Empfangspuffer zurück, und das geht nur eine Weile gut.
Im vorigen Thread hatte Dir das Jens übrigens schon richtig gesagt.
