' schrieb:5) Richtige Antort ist laut Lösung C. Ok, die anderen Antworten kommen auch nicht in Frage. Rolfk sagt: "LV-Funktionen versuchen es, wenn möglich, inplace zu machen.
11) Natürlich ist die Antwort B. Aber wir hatten mal diesen Thread der gezeigt hat, dass auf Grund von einer reduzierten Panelupdate-Rate die Performance besser sein kann, wenn man die lokale Variable vom Indicator benutzt. Ok ... das ist ziemlich klugscheisserisch. Egal.
Ausnahmen bestätigen die Regel (Gilt auch für 5). Wobei man in einer schnell laufenden Schleife eigentlich NIE ein Update eines sichtbaren FP-Elements durchführen sollte, egal ob lokale Variable oder Terminal.
' schrieb:20) Ich hab' da (virtuell) A angekreuzt. Wieso ist das falsch? Etwa weil sich das Bedienelement auf dem FP erst ändert, wenn man das modifizierte Typ-Def. Control abspeichert und das Panel wieder schließt? So kleinlich die Frage?
JA
' schrieb:25) Richtige Antwort C. Was spricht gegen A? ist der entscheidende Hinweis: "längerer Zeitraum?"
Ja, bei "längerem Zeitraum" kann es beim "Tick-Count" zu einem Überlauf kommen, der Ausgang ist schließlich "nur" U32.
' schrieb:28) A, klar. Aber geht auch mit der Node (SGL) ...
Zustimm... Geht natürlich dann auch per Referenz (wieder Signaling-Node) und auch VI-Server... Vielleicht stammt die Frage auch aus "alten" Zeiten, als es die PropertyNode "Signaling" noch nicht gab.
' schrieb:30) Ok, wieder A. Geht aber auch mit TDM. Bzw. würde ich TDMS, je nach Datenmege und sonst noch was, ernsthaft in Erwägung ziehen.
, wieder so eine Frage, man weiß, was man antworten SOLL, auch wenn inzwischen mit dem entsprechenden Plug-In auch TDM und Excel kein Problem mehr ist. Augen zu und durch...
' schrieb:33) A ist richtig. Hab' ich nicht vor kuzem die Vermutung zu hören bekommen, dass C von der Performance identisch sein müsste? Jens?
Aber bei C steht auch wieder While-Schleife. Das müsste man testen. Die "reine" Lehre besagt A.
' schrieb:39) Kann mir einer kurz die Antowrt D erklären?
Ist halt so, PropertyNodes werden grundsätzlich im User-Interface-Thread ausgeführt. Und welcher Teil eines VI läuft im UI, natürlich das Frontpanel. Somit muss das FP in den Speicher geladen werden. Wenn man keine PropertyNodes verwendet und das FP auch nicht anzeigt, dann ist LabVIEW so schlau und lädt das FP erst gar nicht. Folge: Bessere Performance!
' schrieb:Ich mach den CLAD am 21.04 in Köln. Bei dem online Test hab' ich nie alles richtig.
Die "Bestanden"-Quote ist glaube ich 70%. 100% ist IMHO bei den teils schwammigen Fragestellungen kaum möglich.
' schrieb:Ich arbeite aber auch immer nur mit der deutschen Version und den online Test gibt's nur auf engl., oder?
Aber den Test legst du auf deutsch ab. Also, kein Problem. Das kannst du auswählen, ob du ihn auf D oder E machen willst.
Gruß, Jens
