Effizienzsteigerung: Data Viewing & Logging in QSM

(19.10.2015 15:10 )ExXeQtor schrieb:  *Ein Event Handler verarbeitet Eingaben vom Nutzer und sendet Prompts an die QSM
*Eine QSM - Communicator - (die eigentliche State machine), die zum Daten Holen (Treiber) und Processen gut ist
*Eine QSM - Data Consumer - die im Wesentlichen immer dann, wenn ein Datenpaket vom Communicator in die Queue gelegt wurde, dieses herausholt und
a) Zur Visualisierung in Charts steckt
b) in Textdateien loggt.

So mach ich das auch. Nur: Die Sache mit den Queues mach ich noch viel mehr ...

Mach dir viele QSM (bei mir heißen diese VIs Klassen und sind FGVs), wo jede eine genau definiert Aufgabe hat. z.B. eine FGV für Loggen. Diese FGV, weil ja eine Klasse, hat ein Property, das Loggen heißt. Mit dem Aufruf dieses Property (über einen Enumerator ...) wird Klassen-intern(!) das Flag "Loggen" manipuliert. Diese Vorgehensweise hat den Vorteil, dass ein Algorithmus (Daten loggen) von der Bedieneroberfläche getrennt wird (Property-Node). Nächster Vorteil: Ein VI wird schön klein und übersichtlich. Alles das, was du jetzt als Algorithmus "Loggen" (File schreiben etc.) siehst, wird dann als ein einziger VI-Aufruf (Daten per Queue an Modul senden), erscheinen.

Ebendieses gilt natürlich auch für die Anzeige im Graph. QSM (als FGV mit private-variablen) machen, Daten und Steuerwerte per Queue senden: Wenn der Anwender (oder wer auch immer) ctrl_accel_range ändert, wird genau in dem Moment, in dem geändert wird, einmalig der Steuerwert ctrl_accel_range in die QSM geschickt - und dort als ganz normale private Variable (z.B. in einem Schieberegister) verwaltet ...

Anzeige