Nachdem ich beim durchstöbern auf den Hinweis gestossen bin, dass Zugriffe auf Variablenwerte sehr langsam sein sollen, hab' ich ein kleines Testprogramm geschrieben und war entsetzt!
Der Zugriff mittel Referenz:Wert ist ca. um den Faktor 4000 langsamer als bei direktem Zugriff oder per lokaler Variable.
Ich hab' das Testprogramm mal angehängt (Labview 2021).
Vielleicht kann mir jemand das Ergebniss bestätigen?
Hallo Hajo,
ich kann bestätigen, dass Property Nodes sehr langsam sind...
Zu deinem VI kann ich nichts sagen, da du mit LV2021 arbeitest. Wenn du es aber in LV2020 bereitstellen könntest!?
Wo genau nimmst du deine Behauptung her? Quellen?
Hallo Gerd,
der Faktor wird bei meinem Testprogramm berechnet.
Version LV2020 hab' ich angehängt.
Hallo Hajo,
danke fürs Konvertieren!
Ja, lokale Variablen sind schnell - sonlange es sich um skalare Werte handelt.
Wenn du aber anfängst mit größeren Arrays zu hantieren, kann sich der Aufwand für den Memorymanager schon deutlicher bemerkbar machen: lokale Variablen erfordern (fast) immer Kopien des Werts des FP-Elements!
Das gleiche gilt auch für globale Variablen: sie sind schnell und haben die gleichen Probleme wie lokale Variablen.
PropertyNodes sind im Vergleich dazu (extrem) langsam, weshalb man sie nicht als schnöden Ersatz für lokale Variablen (d.h. Property "Value") verwenden soll. Es gibt aber legitime Einsatzzwecke, die aber trotzdem nicht in einer auf Geschwindigkeit getrimmten Schleife erfolgen sollten!
(Außerdem gibt es da noch die FP-Property DeferFPUpdates, das beschleunigt die PropertyNodes immerhin um den Faktor 3 in deinem VI…)
Es gibt außerdem auch noch SharedVariables in LabVIEW, die ebenfalls nicht auf Geschwindigkeit getrimmt sind.
Alle Konstrukte/Optionen haben ihre Einsatzzwecke, und dafür kann/sollte man sie nutzen!
Diese Beobachtung ist ein alter Hut.
Der Grund dafür ist die notwendige Kommunikation zwischen zwei Threads, dem Bockdiagramm-Thread und dem Frontpanel/UI-Thread.
Zum Hintergrund: LABVIEW implementiert das Datenfluss-Paradigma. In LabVIEW gibt es KEINE Variablen! Es gibt nur Datenquellen und Datensenken. An Drahtabzweigen werden potentiell Kopien der Drahtinhalte erzeugt. Deshalb ist LabVIEW thread-save und kann Code-Segmente gefahrlos paralelisieren. Auch lokale oder globale Variablen sind keine, sondern Speichersegmente, die von der LabVIEW Runtime-Engine asynchron abgeglichen werden. Geschrieben wird an das Original, gelesen wird von Speicherkopien. Das ist eine häufige Ursache von Race-Conditions.
Je besser Du den Datenfluss verinnerlichst und konsequent anwendest, zusammen mit den bekannten Ereignissmechanismen, Queue, Notifier, User Defined Events etc., desto effizienter und performanter werden Deine LabVIEW Programme.
Gruß Holger
Verständnisfrage, da ich nur 2019 habe:
Bei den Property Nodes ist es für die Laufzeit uninteressant ob ich mir eine spezifische nehme (ohne Referenzeingang) oder eine in die ich die Referenz reingebe um das FP zu addressieren?
Grundsätzlich arbeite ich gerne mit Value (signaling) um nur die Programmreaktionen auf Userinteraktionen ausprogrammieren zu müssen und wenn sich die ändern sollen nicht zwei Teile im Code ersetzen zu müssen. Man könnte das natürlich mit einer Queue koppeln die das eigentliche Event weiterreicht zur Abarbeitung, so dass man statt "Value (signaling)" einfach direkt in die Queue schreiben kann. macht das den Code deutlich schneller? Zumindest die FP Interaktion entfällt dabei ja wenn die Aktionen aus dem Blockdiagram kommen.
Gruß Kiesch
P.S: In welcher Größenordnung der Laufzeit bewegen wir uns? µs für den Property Node Zugriff? Das wäre für mich in fast allen Fällen in denen ich die einsetze nicht relevant.
Danke an Holger und Gerd für die Erklärungen. Hilft mir wieder etwas mehr im Verständniss.
@Holger: Mich hat der Faktor 4000 erschreckt. Die Beobachtung "viel langsamer" und "extrem lahm" ect. war zu schwammig, daher hab' ich mir mal das o.g. Texstprogramm gebastelt um konkretere Daten präsentieren zu können (wenn ich andere Programmierer von "meinem" Stil überzeugen möchte).
Zu meiner Motivation:
Wir programmieren Dauerlaufprüfstände, welche für einzelne Messungen bis zu 4 Wochen laufen müssen. Dabei werden Datenpakete im zweistelligen kB Bereich pro sekunde abgerufen und auf Grenzen, Nulldurchgänge ect. überprüft. Hier machen sich schnelle Zugriffe auf Einzelwerte durchaus bemerkbar. Verluste von Messungen werden aber erst nach 4 Wochen bemerkt, damit dann Änderungen vorgenommen werden können.
"Verluste von Messungen werden aber erst nach 4 Wochen bemerkt,..."
Und wenn Daten fehlen? Muss die Messung dann wiederholt werden? Ernsthaft? Es werden keine periodischen Checks auf Vollständigkeit und Qualität durchgeführt?
Das kann ich kaum glauben.
Gruß Holger
"Value (signaling)"
Sieh Dir mal die Beispiele zu User Defined Events an.
Gruß Holger
(30.07.2022 14:55 )BNT schrieb: [ -> ]"Verluste von Messungen werden aber erst nach 4 Wochen bemerkt,..."
Und wenn Daten fehlen? Muss die Messung dann wiederholt werden? Ernsthaft? Es werden keine periodischen Checks auf Vollständigkeit und Qualität durchgeführt?
Das kann ich kaum glauben.
Gruß Holger
Die Auswertung erfolgt nach der Messung. Online können nur einfache Kriterien aufgenommen werden, wie z.B. ein erwarteter Nulldurchgang und die Anzahl der Messungen pro erkanntem Zyklus.
Detaillierte Auswertungen (z.B. Fourrieranalyse, Phasensprünge, sprunghafter Versatz des Messniveau) werden dann über ca. 5 Mio Zyklen gemacht und über eine 3-Dim Auswertung dargestellt. Erst dort werden dann kritische Fehler erkannt.
Die Messung wird auch zur Dokumentation und Langzeitstabilität des Endprodukts benötigt und pro Fertigungslos einmal durchgeführt.
Es werden auch nicht alle Zyklen im Protokoll dargestellt, sondern, wenn alle "einfachen" Grenzen eingehalten werden, nur periodisch einzelne Zyklen. Es muss jedoch gewährleistet sein, dass kein Messwert vorgegebene Grenzen verletzt - also jeder Messpunkt zählt!
... und es ist tatsächlich so, dass eine Fehlmessung eine Wiederholung notwendig macht. Beim Endprodukt handelt es sich um äusserst hochwertige Komponenten, die im real Life Betrieb mehrere Millionen Zyklen zuverlässig innerhalb der garantierten Parameter hinter sich bringen müssen.
Periodische Checks auf Vollständigkeit sind wegen mechanischen Ungenauigkeiten und nicht-linearitäten nur unzuverlässig und deshalb wenig aussagekräftig.